Re: [cmake-developers] [PATCH 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation
On 06/20/2014 01:09 PM, Philipp Möller wrote:
+# Boost::boost - interface target containing the include
+# directory
Nice.
+ if(Boost_USE_STATIC_LIBS)
+add_library(Boost::${COMPONENT} STATIC IMPORTED)
+ else()
+add_library(Boost::${COMPONENT} SHARED IMPORTED)
+ endif()
IIRC, Boost_USE_STATIC_LIBS asks for static libraries, but when it is
OFF we might still get static libraries. Therefore the else() case
still needs to mark it as UNKNOWN.
Thanks,
-Brad
--
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 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation
Brad King wrote: On 06/20/2014 01:09 PM, Philipp Möller wrote: +# Boost::boost - interface target containing the include +# directory Nice. Note that Boost upstream is modularizing and may provide CMake config files in the future: https://github.com/boost-cmake/boost-cmake https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus The wiki page is out of date, and so is the repo, because boost is trying to make a release before finishing the modularization work and it is all on- hold for several more months. This means: 1) Creating a Boost::boost monolithic target may not be appropriate 2) If FindBoost creates imported targets named Boost::*, then config files provided by boost upstream probably can't use that namespace (currently it uses boost::, but you might consider whether imported targets provided by files shipped with cmake should use CMake::). Thanks, Steve. -- 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 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation
On 06/24/2014 08:42 AM, Stephen Kelly wrote: Note that Boost upstream is modularizing and may provide CMake config files in the future: This would be greatly preferred over FindBoost. As Qt5 demonstrates, it is possible to provide package configuration files for CMake even for a project that does not build with CMake. -Brad -- 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 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation
Stephen Kelly steve...@gmail.com writes: Brad King wrote: On 06/20/2014 01:09 PM, Philipp Möller wrote: +# Boost::boost - interface target containing the include +# directory Nice. Note that Boost upstream is modularizing and may provide CMake config files in the future: https://github.com/boost-cmake/boost-cmake https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus The wiki page is out of date, and so is the repo, because boost is trying to make a release before finishing the modularization work and it is all on- hold for several more months. This project has been going on for ages and considering how long it took Boost to change their SCM or the (stalled?) ryppl and 0install efforts I don't see this happening anytime soon. I'm of course not belittling any of those efforts or the people behind them. Huge organizations are hard to move and those that try deserve respect. It would certainly make my life easier if they succeeded. Exporting targets with proper dependencies is a problem now and lots of projects depend on Boost. Improving the process now and even supporting older versions of Boost is, IMO, worthwhile. This means: 1) Creating a Boost::boost monolithic target may not be appropriate IMO, even a modularized boost build should provide a target that just gives you all of the includes for convenience in addition to more fine-grained access, but I see why one would think otherwise. 2) If FindBoost creates imported targets named Boost::*, then config files provided by boost upstream probably can't use that namespace (currently it uses boost::, but you might consider whether imported targets provided by files shipped with cmake should use CMake::). Yes, I was thinking about that. So far I have only applied those changes for packages which are highly unlikely to ever provide package configs and so giving them their own namespace made sense to me. Their is also a problem that some find-modules don't use other find-modules even where they should (e.g. FindGLUT which is using Xmu and Xi, which could be provided by FindX11). This could lead to inconsistencies between targets, thus the encapsulation in the GLUT namespace. Boost is a bit of a special case and changing the namespace to indicate that one is using the CMake provided targets might be a good idea. What about FindBoost::? -- 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 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation
Brad King brad.k...@kitware.com writes:
On 06/20/2014 01:09 PM, Philipp Möller wrote:
+# Boost::boost - interface target containing the include
+# directory
Nice.
+ if(Boost_USE_STATIC_LIBS)
+add_library(Boost::${COMPONENT} STATIC IMPORTED)
+ else()
+add_library(Boost::${COMPONENT} SHARED IMPORTED)
+ endif()
IIRC, Boost_USE_STATIC_LIBS asks for static libraries, but when it is
OFF we might still get static libraries. Therefore the else() case
still needs to mark it as UNKNOWN.
You are right. Attached is a fixed patch.
commit 240cfd47a4980965f18068f6f35c6b7071497d32
Author: Philipp Möller bootsare...@googlemail.com
Date: Fri Jun 20 19:09:28 2014 +0200
FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation
diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index dfd4460..705b250 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -53,6 +53,24 @@
# Boost_C_LIBRARY_DEBUG - Component C library debug variant
# Boost_C_LIBRARY_RELEASE - Component C library release variant
#
+# In addition to the above variables this module creates the following
+# :prop_tgt:`IMPORTED` targets::
+#
+# Boost::boost - interface target containing the include
+# directory
+# Boost::C- shared or static library target for a
+# component (C is lower-case)
+# Boost::diagnostic_definitions - interface target to enable diagnostic
+# information about Boost's automatic linking
+# during compilation
+#
+# Component targets never depend on each even though they might
+# require each other. It is important to note that the imported
+# targets behave differently than variables created by this module:
+# multiple calls to find_package(Boost) in the same directory or
+# sub-directories with different options (e.g. static or shared) will
+# not override the values of the targets created by the first call.
+#
# Users may set these hints or results as cache entries. Projects
# should not read these entries directly but instead use the above
# result variables. Note that some hint names start in upper-case
@@ -524,6 +542,13 @@ if(Boost_DEBUG)
Boost_NO_SYSTEM_PATHS = ${Boost_NO_SYSTEM_PATHS})
endif()
+# Supply Boost_LIB_DIAGNOSTIC_DEFINITIONS as a convenience target. It
+# will only contain any interface definitions on WIN32, but is created
+# on all platforms to keep end user code free from platform dependent
+# code.
+if(NOT TARGET Boost::diagnostic_definitions)
+ add_library(Boost::diagnostic_definitions INTERFACE IMPORTED)
+endif()
if(WIN32)
# In windows, automatic linking is performed, so you do not have
# to specify the libraries. If you are linking to a dynamic
@@ -543,6 +568,8 @@ if(WIN32)
# code to emit a #pragma message each time a library is selected
# for linking.
set(Boost_LIB_DIAGNOSTIC_DEFINITIONS -DBOOST_LIB_DIAGNOSTIC)
+ set_target_properties(Boost::diagnostic_definitions PROPERTIES
+INTERFACE_COMPILE_DEFINITIONS BOOST_LIB_DIAGNOSTIC)
endif()
_Boost_CHECK_SPELLING(Boost_ROOT)
@@ -1155,11 +1182,36 @@ else()
endif()
#
-# Notification to end user about what was found
+# Notification to end user about what was found and creation of targets.
#
set(Boost_LIBRARIES )
if(Boost_FOUND)
+ if(NOT TARGET Boost::boost)
+add_library(Boost::boost INTERFACE IMPORTED)
+set_target_properties(Boost::boost PROPERTIES
+ INTERFACE_INCLUDE_DIRECTORIES ${Boost_INCLUDE_DIR})
+ endif()
+
+ foreach(COMPONENT ${Boost_FIND_COMPONENTS})
+string(TOUPPER ${COMPONENT} UPPERCOMPONENT)
+
+if(NOT TARGET Boost::${COMPONENT})
+ if(Boost_USE_STATIC_LIBS)
+add_library(Boost::${COMPONENT} STATIC IMPORTED)
+ else()
+# Even if Boost_USE_STATIC_LIBS is OFF, we might have static
+# libraries as a result.
+add_library(Boost::${COMPONENT} UNKNOWN IMPORTED)
+ endif()
+
+ set_target_properties(Boost::${COMPONENT} PROPERTIES
+IMPORTED_LOCATION ${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}
+IMPORTED_LOCATION_RELEASE ${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}
+IMPORTED_LOCATION_DEBUG ${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG})
+endif()
+ endforeach()
+
if(NOT Boost_FIND_QUIETLY)
message(STATUS Boost version: ${Boost_MAJOR_VERSION}.${Boost_MINOR_VERSION}.${Boost_SUBMINOR_VERSION})
if(Boost_FIND_COMPONENTS)
--
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
Re: [cmake-developers] [PATCH 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation
Philipp Moeller wrote: Stephen Kelly steve...@gmail.com writes: The wiki page is out of date, and so is the repo, because boost is trying to make a release before finishing the modularization work and it is all on- hold for several more months. This project has been going on for ages and considering how long it took Boost to change their SCM or the (stalled?) ryppl and 0install efforts I don't see this happening anytime soon. Indeed. Until a few weeks ago I believed the effort was permanently aborted. Then some Boost people starting doing the modularization work, but were asked to stop until after the next release (I don't know the details of that reasoning). After the major part of the modularization TODO is done, it would be viable to start talking about whether they want to use cmake, and if not, teaching bjam to create cmake config packages. As you note, this is several months away. As far as I know, they want to make their release in early August, but I have no idea what blocks that or if it is likely that they will reach that target. I'm just noting all of this for informational purposes :). This means: 1) Creating a Boost::boost monolithic target may not be appropriate IMO, even a modularized boost build should provide a target that just gives you all of the includes for convenience in addition to more fine-grained access, but I see why one would think otherwise. In a modularized system, all of boost might not be there, and the parts that are might be in different places. Thanks, Steve. -- 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 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation
Stephen Kelly steve...@gmail.com writes: Philipp Moeller wrote: Stephen Kelly steve...@gmail.com writes: The wiki page is out of date, and so is the repo, because boost is trying to make a release before finishing the modularization work and it is all on- hold for several more months. This project has been going on for ages and considering how long it took Boost to change their SCM or the (stalled?) ryppl and 0install efforts I don't see this happening anytime soon. Indeed. Until a few weeks ago I believed the effort was permanently aborted. Then some Boost people starting doing the modularization work, but were asked to stop until after the next release (I don't know the details of that reasoning). After the major part of the modularization TODO is done, it would be viable to start talking about whether they want to use cmake, and if not, teaching bjam to create cmake config packages. As you note, this is several months away. As far as I know, they want to make their release in early August, but I have no idea what blocks that or if it is likely that they will reach that target. I'm just noting all of this for informational purposes :). This means: 1) Creating a Boost::boost monolithic target may not be appropriate IMO, even a modularized boost build should provide a target that just gives you all of the includes for convenience in addition to more fine-grained access, but I see why one would think otherwise. In a modularized system, all of boost might not be there, and the parts that are might be in different places. Sorry, poor wording on my part. I meant to say a target for all of boost that is available. It should be easy to support includes in different locations by just having the Boost::includes target consist of dependencies on Boost::component_includes targets. This is of course contrary to what modularization is supposed to achieve, but sometimes a little convenience helps adoption a lot. -- 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] [PATCH 5/5] FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation
---
Modules/FindBoost.cmake | 52 -
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index dfd4460..b989957 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -53,6 +53,24 @@
# Boost_C_LIBRARY_DEBUG - Component C library debug variant
# Boost_C_LIBRARY_RELEASE - Component C library release variant
#
+# In addition to the above variables this module creates the following
+# :prop_tgt:`IMPORTED` targets::
+#
+# Boost::boost - interface target containing the include
+# directory
+# Boost::C- shared or static library target for a
+# component (C is lower-case)
+# Boost::diagnostic_definitions - interface target to enable diagnostic
+# information about Boost's automatic linking
+# during compilation
+#
+# Component targets never depend on each even though they might
+# require each other. It is important to note that the imported
+# targets behave differently than variables created by this module:
+# multiple calls to find_package(Boost) in the same directory or
+# sub-directories with different options (e.g. static or shared) will
+# not override the values of the targets created by the first call.
+#
# Users may set these hints or results as cache entries. Projects
# should not read these entries directly but instead use the above
# result variables. Note that some hint names start in upper-case
@@ -524,6 +542,13 @@ if(Boost_DEBUG)
Boost_NO_SYSTEM_PATHS = ${Boost_NO_SYSTEM_PATHS})
endif()
+# Supply Boost_LIB_DIAGNOSTIC_DEFINITIONS as a convenience target. It
+# will only contain any interface definitions on WIN32, but is created
+# on all platforms to keep end user code free from platform dependent
+# code.
+if(NOT TARGET Boost::diagnostic_definitions)
+ add_library(Boost::diagnostic_definitions INTERFACE IMPORTED)
+endif()
if(WIN32)
# In windows, automatic linking is performed, so you do not have
# to specify the libraries. If you are linking to a dynamic
@@ -543,6 +568,8 @@ if(WIN32)
# code to emit a #pragma message each time a library is selected
# for linking.
set(Boost_LIB_DIAGNOSTIC_DEFINITIONS -DBOOST_LIB_DIAGNOSTIC)
+ set_target_properties(Boost::diagnostic_definitions PROPERTIES
+INTERFACE_COMPILE_DEFINITIONS BOOST_LIB_DIAGNOSTIC)
endif()
_Boost_CHECK_SPELLING(Boost_ROOT)
@@ -1155,11 +1182,34 @@ else()
endif()
#
-# Notification to end user about what was found
+# Notification to end user about what was found and creation of targets.
#
set(Boost_LIBRARIES )
if(Boost_FOUND)
+ if(NOT TARGET Boost::boost)
+add_library(Boost::boost INTERFACE IMPORTED)
+set_target_properties(Boost::boost PROPERTIES
+ INTERFACE_INCLUDE_DIRECTORIES ${Boost_INCLUDE_DIR})
+ endif()
+
+ foreach(COMPONENT ${Boost_FIND_COMPONENTS})
+string(TOUPPER ${COMPONENT} UPPERCOMPONENT)
+
+if(NOT TARGET Boost::${COMPONENT})
+ if(Boost_USE_STATIC_LIBS)
+add_library(Boost::${COMPONENT} STATIC IMPORTED)
+ else()
+add_library(Boost::${COMPONENT} SHARED IMPORTED)
+ endif()
+
+ set_target_properties(Boost::${COMPONENT} PROPERTIES
+IMPORTED_LOCATION ${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}
+IMPORTED_LOCATION_RELEASE ${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}
+IMPORTED_LOCATION_DEBUG ${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG})
+endif()
+ endforeach()
+
if(NOT Boost_FIND_QUIETLY)
message(STATUS Boost version: ${Boost_MAJOR_VERSION}.${Boost_MINOR_VERSION}.${Boost_SUBMINOR_VERSION})
if(Boost_FIND_COMPONENTS)
--
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
