Re: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0
Am Samstag, 18. Juni 2016, 14:41:34 schrieb Rolf Eike Beer: > Ben Boeckel wrote: > > Hi, > > > > Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks > > for that. However, it is hidden behind the check that pkg_check_modules > > > > uses to see if it already ran: > > if (NOT DEFINED __pkg_config_checked_${_prefix} OR > > > > __pkg_config_checked_${_prefix} LESS ${PKG_CONFIG_VERSION} OR > > NOT ${_prefix}_FOUND) > > > > which means that on the second configure, the target is not created > > causing build faiures. Could you please look at reordering the logic so > > that the imported target is always created (if requested)? Thanks. > > > > Brad, this is in the rc releases; what should be done? Block the > > release, undocument the feature, or wait for a patch? > > Please check if > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3213b747a84a4e584e9edc6b > d8c114b809b18bec fixes it for you. Version without stupid typo: https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8345c6463d813fb39ee6a6dee5259ee18525c62c signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Imported Locations in FindBoost.cmake
Hi there, I ran into a small issue with the new imported target interface of FindBoost.cmake. Just like the old variable-based interface, the script only detects Debug and Release configurations of installed Boost binaries. In the old interface, the debug binaries where used only for debug builds (care of the debug keyword in the classic target_link_libraries function), while the release binaries were used for all other configurations (optimized keyword). It seems that with the new interface, this was inverted. On MSVC for instance, the RelWithDebInfo and MinSizeRel configurations use the debug binaries of Boost. This is not desirable and can even break those configurations on MSVC due to inconsistent use of the debug runtime and STL debug iterators. After fiddling around with the issue, I found that reversing the order in which the IMPORTED_LOCATION_* fields on the imported target are being set resolves the issue. It seems that the first configuration that's added here will be used as a default for the not explicitly added configurations? I attached a small patch to demonstrate what I mean, but I am unsure if this is a proper fix for the issue. Thanks and regards, Andreas From c201749b494c5aa44d7cc6c9139d8c71db849cf2 Mon Sep 17 00:00:00 2001 From: Andreas Weis Date: Sun, 19 Jun 2016 12:44:29 +0200 Subject: [PATCH] Switched order of adding locations to imported target FindBoost only detects Debug and Release configurations; All other configurations will fall back to whichever IMPORTED_LOCATION_ was added *first*. This change makes sure that that is the Release configuration. Adding Debug first is likely to cause conflicts on MSVC, where the Debug runtime is not to be used for RelWithDebInfo and MinSizeRel builds. --- Modules/FindBoost.cmake | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake index 6bf6401..2560459 100644 --- a/Modules/FindBoost.cmake +++ b/Modules/FindBoost.cmake @@ -1734,13 +1734,6 @@ if(Boost_FOUND) IMPORTED_LINK_INTERFACE_LANGUAGES "CXX" IMPORTED_LOCATION "${Boost_${UPPERCOMPONENT}_LIBRARY}") endif() -if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}") - set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY -IMPORTED_CONFIGURATIONS DEBUG) - set_target_properties(Boost::${COMPONENT} PROPERTIES -IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX" -IMPORTED_LOCATION_DEBUG "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}") -endif() if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}") set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE) @@ -1748,6 +1741,13 @@ if(Boost_FOUND) IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX" IMPORTED_LOCATION_RELEASE "${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}") endif() +if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}") + set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY +IMPORTED_CONFIGURATIONS DEBUG) + set_target_properties(Boost::${COMPONENT} PROPERTIES +IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX" +IMPORTED_LOCATION_DEBUG "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}") +endif() if(_Boost_${UPPERCOMPONENT}_DEPENDENCIES) unset(_Boost_${UPPERCOMPONENT}_TARGET_DEPENDENCIES) foreach(dep ${_Boost_${UPPERCOMPONENT}_DEPENDENCIES}) -- 2.5.0.windows.1 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] daemon-mode: Infrastructure
Hi Brad, Am 17.06.2016 22:24 schrieb "Brad King" : > > On 06/13/2016 08:00 PM, Tobias Hunger wrote: > > * There will always be 1 client talking to a server. > > * Client/Server communicate using JSON messages > > Yes. IIRC it is using stdin/stdout (I haven't checked the code), > so limiting to one client is implicit. True. Still it does not hurt to state explicitly, especially considering that I think of the stdin/out as an implementation detail. There is no reason for the code not to switch to pipes or sockets for communication. > In this case, is it actually a daemon? It is not expected to outlive > the client that started it. Perhaps we should consider a different name. I am bad at names:-) Plus Stephen made quite a bit of PR for the CMake daemon idea. > One possible problem with using stdin/stdout is that when CMake runs the > configuration the project code can do things like execute_process that > may share the stdout with the child process. That may allow the child > process to print content formatted to look like the protocol and trick > the client. Ideally all output handling would avoid printing things to > stdout in server/daemon mode, but that may take some effort to achieve. Yes, unexpected output on stdout could cause havok to the parser. So far this worked well though, and the magic string before/after messages prevented any unexpected interactions. > > What do you think? Does this make sense? > > It sounds fine to me. I'll state the caveat that I've had little experience > in maintaining versioned protocols like this though. Hopefully others can > review this too. Yes, I hope other IDE developers will chime in at some point... > On 06/14/2016 04:30 AM, Tobias Hunger wrote: > > I think it would make perfect sense to ship the first cmake version with > > included daemon-mode with a big, fat warning that the interfaces are not > > finalized yet and will change in incompatible ways during the first release > > cycle (or maybe two:-). > > Yes. Should we make the option to activate it different, and include > "experimental" in its name? I think the idea is that no clients should > be released that depend on the experimental behavior in CMake. I now added a patch that allows protocol versions to be marked as experimental. These are only visible to clients that started "cmake -E daemon --experimental". The only existing protocol version is now marked experimental. I think that makes it pretty clear what is experimental and what is not and clients do not need to change (except for maybe dropping the --experimental flag) to go to a stable interface once we are satisfied with the first version. Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
Hi Brad, Am 17.06.2016 22:09 schrieb "Brad King" : > Then I applied the patches with some revisions: > > cmGeneratorTarget: Adopt Fortran module directory generation > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49f10f0d > > cmLocalGenerator: Add method to get Fortran-specific compiler flags > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5467e794 > > cmLocalGenerator: Adopt target compile flag generation > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c488ce8 > > cmExtraSublimeTextGenerator: Use GetTargetCompileFlags > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=802b36fb > > These have been merged to `next` for testing. Wonderful! Thanks for improving the patches I'll rebase my branch on top of these as soon as they hit master. Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Imported Locations in FindBoost.cmake
Hello, On 06/19/2016 02:00 PM, Andreas Weis wrote: > After fiddling around with the issue, I found that reversing the order > in which the IMPORTED_LOCATION_* fields on the imported target are being > set resolves the issue. It seems that the first configuration that's > added here will be used as a default for the not explicitly added > configurations? Seems to be true for me as well. I don't think just reverting the order is a proper fix though. Consider exported target configuration files generated by the CMake itself. They consist of .cmake and a set of -.cmake files which are included from the former in unknown order. At east file(GLOB) documentation doesn't specify the order, but even if it's sorted alphabetically then -debug.cmake always comes before -release.cmake or -relwithdebinfo.cmake. The suggested way to deal with this seems to be to use MAP_IMPORTED_CONFIG_ target properties, but I suppose it should only (?) be used when imported target (or target it's being linked to) has non-standard configurations, which isn't so in this case. Mapping Release to "Release;RelWithDebInfo" and RelWithDebInfo to "RelWithDebInfo;Release" looks odd enough (and I didn't add MinRelSize here). Maybe there should exist some default mapping built-in with the similar effect?.. Regards, Mike -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Patch] Two trivial patches fixing type in CPack/DEB testcase
>>> Here're two trivial patches for testing of CPack/DEB. >>> >>> One is for building cmake on SELinux-enabled system, and other is for a >>> typo in the same file form the former one. Applied to next with extension of first patch to newer tests: https://cmake.org/gitweb?p=cmake.git;a=commit;h=b661d4a Brad could this topic be merged to 3.6 since it is a test fix? Thanks, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] How to set startup project in Visual Studio
Hello, On 06/18/2016 03:15 PM, Stephen Kelly wrote: > a DIRECTORY property VS_STARTUP_PROJECT which sets the start up project in > Visual Studio. I tried it in the 3.6 RC and it works fine if I set the > property in the top-level directory, so thanks for that. > > However, the documentation does not say which directory to set it in, or why > it is a DIRECTORY property. > > Why is this not a GLOBAL property? My guess would be because CMake generates .sln file for each project() call (e.g. if you have additional project() calls in subdirectories apart from the top-level one), and then for each .sln file it would be possible to specify different startup [VS] project. So it's not exactly a directory, but a project property I would say, but there're no "project properties" in CMake. Regards, Mike -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] How to set startup project in Visual Studio
The setting is in a different file that's .vcproj.user (or .user.vcproj) and cmake doesn't write that... would be nice if it could at least write those entiries required... nice thing about xml should be that what's there can be read and used and filled in with the rest of the settings? Well I guess that's really implementation dependant. On Sun, Jun 19, 2016 at 2:42 PM, Mike Gelfand wrote: > Hello, > > On 06/18/2016 03:15 PM, Stephen Kelly wrote: > > a DIRECTORY property VS_STARTUP_PROJECT which sets the start up project > in > > Visual Studio. I tried it in the 3.6 RC and it works fine if I set the > > property in the top-level directory, so thanks for that. > > > > However, the documentation does not say which directory to set it in, or > why > > it is a DIRECTORY property. > > > > Why is this not a GLOBAL property? > My guess would be because CMake generates .sln file for each project() > call (e.g. if you have additional project() calls in subdirectories > apart from the top-level one), and then for each .sln file it would be > possible to specify different startup [VS] project. So it's not exactly > a directory, but a project property I would say, but there're no > "project properties" in CMake. > > Regards, > Mike > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Imported Locations in FindBoost.cmake
On 6/19/2016 9:17 PM, Mike Gelfand wrote: > > The suggested way to deal with this seems to be to use > MAP_IMPORTED_CONFIG_ target properties, but I suppose it should > only (?) be used when imported target (or target it's being linked to) > has non-standard configurations, which isn't so in this case. > Alternatively, maybe it makes sense for FindBoost to simply set all configurations explicitly? By iterating over CMAKE_CONFIGURATION_TYPES (or inspecting CMAKE_BUILD_TYPE for single-config generators) and using the global property DEBUG_CONFIGURATIONS to determine whether a given configuration needs the debug or the release binaries. I'm still unsure what to make of the current fallback-to-first-configuration behavior. I did not find this mentioned anywhere in the docs, so I guess it's not a behavior one should rely upon? I was wondering whether it would make sense to properly define what CMake does in such a case. In particular since, as you mentioned, package configuration files might already rely on some assumptions there. Best regards, Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers