Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMake config scripts installed in non-standard location on MS Windows #1450

Closed
gdkessler opened this issue Oct 13, 2016 · 8 comments
Closed
Assignees

Comments

@gdkessler
Copy link

gdkessler commented Oct 13, 2016

In the 1.7.4 version, the CMake config scripts (e.g. PocoConfig.cmake) are installed in "lib/cmake/Poco", which is not one of the default prefix paths used, by default, when find_package(Poco) is invoked (see https://cmake.org/cmake/help/v3.7/command/find_package.html), although it is one of the default prefix paths use to find the scripts on Unix. For MS Windows, an alternative location that will be looked at by find_package() would be a "cmake" directory. Ex:

if (WIN32)
    set(_CMAKE_INSTALL_DIR "cmake")
else ()
    set(_CMAKE_INSTALL_DIR "lib/cmake/${PROJECT_NAME}")
endif ()
install(
    FILES
        ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}/${PROJECT_NAME}Config.cmake
        ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}/${PROJECT_NAME}ConfigVersion.cmake
    DESTINATION
        "${_CMAKE_INSTALL_DIR}"
    COMPONENT
        Devel
)

Using a non-standard location for the Poco CMake script causes problems when packages are installed in a common location.

@bachp
Copy link
Member

bachp commented Oct 14, 2016

I actually think it's bad from CMake side to not have a common location that works on all platforms.
But I agree in this case we should change it as you proposed.

Could you submit a PR for this?

@gdkessler
Copy link
Author

I completely agree that it is bad that the CMake find_package default search path does not have a common location that works on all platforms.

I would be happy to submit a PR with the modification I suggested above.

@gocarlos
Copy link

is this fixed?

@aleks-f
Copy link
Member

aleks-f commented May 27, 2018

i don't think it is in 1.x, develop probably. @Bjoe would know details

@zosrothko
Copy link
Member

FYI, the installation directory for Poco with 32 arch should be in C:\Program Files (x86)\Poco\<vsversion>
and for the 64 arch in C:\Program Files\Poco\<vsversion> where <vsversion> should be "VSYYYY" because a user can decide to install poco-1.X on a single machine with VS2008, VS2010, VS2012, VS2015, VS2017

@gdkessler
Copy link
Author

I would note that the issue here is where the cmake configuration scripts are installed within the main installation directory for Poco, not where the main installation directory is set to. I would also caution against hard-coding the installation directory, even though the default that cmake uses might not be able to disambiguate between compiler versions. In general, choosing the installation directory is handled in the installation-specific configuration step, and not providing an installation directory has a well-understood default. It should always be possible to override the installation directory with the CMAKE_INSTALL_PREFIX. If a user decides to use subdirectories to be able to install VS2008, VS2010, VS2012, VS2015, and VS2017 versions in C:\Program Files\Poco<vsversion> and C:\Program Files (x86)\Poco<vsversion>, then that can be done by setting the CMAKE_INSTALL_PREFIX appropriately for each compiler version and architecture. If the proposal is to have an installation script outside of the CMake script do just that, then that sounds good to me. I just wanted to suggest that a direct use of the CMake script to build one instance of the library should follow the expected CMake behavior in terms of installation. Thanks.

@Bjoe
Copy link
Contributor

Bjoe commented Jun 10, 2018

@aleks-f Well the #1454 fix is merged into develop not in 1.x
@gdkessler Hm, sorry I didn't get you, It is possible to set CMAKE_INSTALL_PREFIX ....

@gocarlos
Copy link

Eventually related: pocoproject/conan-poco#49

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants