Re: [cmake-developers] cmake_cxx_link_executable issue
On 06/24/2014 09:15 AM, Piotr Bialek wrote: This might have been more appropriate for the user's mailing list since it does not involve development of CMake itself. I'm trying to cross compile with clang. I set cmake_compiler, cmake_linker, etc. During the linking CXX executable all flags, libs, files, etc. are getting from somehow created file ./Main/CMakeFiles/Build.dir/link.txt. The problem is, that when I change linker by setting CMAKE_CXX_LINK_EXECUTABLE, no files or flags are generated in link.txt and I get message like: x86_64-pc-linux-gnu-ld: no input files. The CMAKE_CXX_LINK_EXECUTABLE variable does not refer to the linker executable. It contains the rule used to link executables: http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_LANG_LINK_EXECUTABLE.html You shouldn't have to modify it. For a link CMake calls the compiler (and the compiler invokes the linker). To set the compiler you can use: http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_LANG_COMPILER.html Or the CC and CXX environment variables. The compilers have to be set on the initial CMake run. For a native build with clang on GNU/Linux this can be as simple as e.g.: CC=clang CXX=clang++ cmake [...] Nils -- 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 4/5] FindGLUT.cmake: Add imported targets and documentation
On 06/10/2014 05:55 AM, Philipp Möller wrote: The APPLE part works, but definitely could be improved upon. [snip] +if(APPLE) + # Using the hardcoded paths is certainly not the best thing to + # do, but it is done the include path already. + set_target_properties(GLUT::GLUT PROPERTIES +IMPORTED_LOCATION /System/Library/Frameworks/GLUT.framework/GLUT) + if(NOT TARGET GLUT::Cocoa) +add_library(GLUT::Cocoa UNKNOWN IMPORTED) +set_target_properties(GLUT::Cocoa PROPERTIES + IMPORTED_LOCATION /System/Library/Frameworks/Cocoa.framework/Cocoa) + endif() + set_target_properties(GLUT::GLUT PROPERTIES +INTERFACE_LINK_LIBRARIES GLUT::Cocoa) +else() The path to the framework is hard-coded for the include path only as a possible search location, not as a result. The above code hard-codes it as a result. FindGLUT is one of the only modules left that hard-codes -framework XYZ as a result on OS X instead of allowing find_library to locate the framework. That needs to be fixed first, and then the framework path can be handled here the same way as it is in FindOpenGL. 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
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 0/5] IMPORTED targets for some Find modules
On 06/20/2014 05:00 PM, Philipp Möller wrote: To simplify exporting targets I added IMPORTED targets to some of the Find modules. Thanks! I've applied the first three: FindZLIB: Add imported target and documentation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5a7ff421 FindGLEW: Add imported target and documentation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3d82a223 FindX11: fix documentation formatting error http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c90c7fca I will respond to the individual patch messages for the other two. Unfortunately targets behave differently than variables and can give different results when multiple find_package calls with different hints or options are made. That is not really supported anyway because we have only one CMakeCache.txt so there is only one FOO_LIBRARY variable. A project can achieve it with careful handling and typically by keeping the find_package calls in separate directories where imported targets are scoped apart anyway. -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
[cmake-developers] Weird build error against libc++ on OS X 10.7 (cutting at 1024 characters)
Dear CMake developers, I tried to compile CMake against libc++ on OS X 10.7. For a weird reason it fails: Built target cmsysTestsC [ 25%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/frm_scale.c.o [ 25%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/IOStream.cxx.o [ 25%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/frm_sub.c.o [ 25%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/frm_user.c.o [ 26%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/frm_win.c.o [ 26%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_alnum.c.o [ 26%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_alpha.c.o [ 27%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_enum.c.o [ 27%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_int.c.o [ 27%] [ 27%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.cxx.o Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_ipv4.c.o [ 28%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_num.c.o [ 28%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_regex.c.o Linking C static library libcmForm.a ar: C: No such file or directory make[2]: *** [Source/CursesDialog/form/libcmForm.a] Error 1 make[2]: Leaving directory `/path/to/cmake-3.0.0' make[1]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs Linking CXX static library libcmsys.a make[2]: Leaving directory `/path/to/cmake-3.0.0' [ 28%] Built target cmsys make[1]: Leaving directory `/path/to/cmake-3.0.0' make: *** [all] Error 2 When I use make again and a single core, it fails with [ 66%] Building CXX object Source/CMakeFiles/CMakeLib.dir/cmNinjaUtilityTargetGenerator.cxx.o cd /path/to/cmake-3.0.0/Source /usr/bin/clang++ -DCMAKE_BUILD_WITH_CMAKE -pipe -Os -arch x86_64 -stdlib=libc++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.7 -I/path/to/cmake-3.0.0/Utilities -I/path/to/cmake-3.0.0/Source -I/opt/libcxxlocal/include -I/path/to/cmake-3.0.0/Utilities/cmcompress -I/path/to/cmake-3.0.0/Source/CTest -I/path/to/cmake-3.0.0/Source/CursesDialog/form-o CMakeFiles/CMakeLib.dir/cmNinjaUtilityTargetGenerator.cxx.o -c /path/to/cmake-3.0.0/Source/cmNinjaUtilityTargetGenerator.cxx Linking CXX static library libCMakeLib.a cd /path/to/cmake-3.0.0/Source /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -P CMakeFiles/CMakeLib.dir/cmake_clean_target.cmake cd /path/to/cmake-3.0.0/Source /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/CMakeLib.dir/link.txt --verbose=1 /usr/bin/ar cr libCMakeLib.a CMakeFiles/CMakeLib.dir/cmStandardIncludes.cxx.o CMakeFiles/CMakeLib.dir/cmArchiveWrite.cxx.o CMakeFiles/CMakeLib.dir/cmBootstrapCommands1.cxx.o CMakeFiles/CMakeLib.dir/cmBootstrapCommands2.cxx.o CMakeFiles/CMakeLib.dir/cmCacheManager.cxx.o CMakeFiles/CMakeLib.dir/cmCommands.cxx.o CMakeFiles/CMakeLib.dir/cmCommandArgumentLexer.cxx.o CMakeFiles/CMakeLib.dir/cmCommandArgumentParser.cxx.o CMakeFiles/CMakeLib.dir/cmCommandArgumentParserHelper.cxx.o CMakeFiles/CMakeLib.dir/cmComputeComponentGraph.cxx.o CMakeFiles/CMakeLib.dir/cmComputeLinkDepends.cxx.o CMakeFiles/CMakeLib.dir/cmComputeLinkInformation.cxx.o CMakeFiles/CMakeLib.dir/cmComputeTargetDepends.cxx.o CMakeFiles/CMakeLib.dir/cmCryptoHash.cxx.o CMakeFiles/CMakeLib.dir/cmCustomCommand.cxx.o CMakeFiles/CMakeLib.dir/cmCustomCommandGenerator.cxx.o CMakeFiles/CMakeLib.dir/cmDefinitions.cxx.o CMakeFiles/CMakeLib.dir/cmDepends.cxx.o CMakeFiles/CMakeLib.dir/cmDependsC.cxx.o CMakeFiles/CMakeLib.dir/cmDependsFortran.cxx.o CMakeFiles/CMak ar: CMakeFiles/CMak: No such file or directory make[2]: *** [Source/libCMakeLib.a] Error 1 make[1]: *** [Source/CMakeFiles/CMakeLib.dir/all] Error 2 make: *** [all] Error 2 The weird part is that part of the command is simply cut off: CMakeFiles/CMakeLib.dir/cmDependsFortran.cxx.o CMakeFiles/CMakcut I looked into Source/CMakeFiles/CMakeLib.dir/link.txt. The first line in that file contains 5356 characters, but the line gets cut off at exactly 1024 when printed on the screen and fails with ar: CMakeFiles/CMak: No such file or directory For some reason the command /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/CMakeLib.dir/link.txt --verbose=1 isn't outputting the whole command, but cutting it in the middle instead. If I execute that command from link.txt manually, it works ok and the build continues. It then fails again with cd /path/to/cmake-3.0.0/Source /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/ccmake.dir/link.txt --verbose=1 /usr/bin/clang++ -pipe -Os -arch x86_64 -stdlib=libc++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.7
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] Ninja order-only dependency makes inefficient ninja DAG
On 06/24/2014 07:11 AM, Kristofer Tingdahl wrote: CMake adds order-only dependencies in build.ninja between libraries and subsequent object-files, and I cannot see why this is needed. The object files of consuming targets might use headers generated by custom commands in earlier targets. The order-only dependencies ensure a safe build for such cases. They are not always needed, and the extra dependencies could be removed with sufficient work on the generator. See these issues: Optionally disable build order dependency target_link_libraries http://www.cmake.org/Bug/view.php?id=13799 target_link_libraries may have option not to add dependencies, for archive target http://www.cmake.org/Bug/view.php?id=14726 Generalize LINK_ONLY http://www.cmake.org/Bug/view.php?id=14751 and a workaround mentioned here: http://www.cmake.org/Bug/view.php?id=14726#c35023 -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
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 4/5] FindGLUT.cmake: Add imported targets and documentation
Brad King brad.k...@kitware.com writes:
On 06/10/2014 05:55 AM, Philipp Möller wrote:
The APPLE part works, but definitely could be improved upon.
[snip]
+if(APPLE)
+ # Using the hardcoded paths is certainly not the best thing to
+ # do, but it is done the include path already.
+ set_target_properties(GLUT::GLUT PROPERTIES
+IMPORTED_LOCATION /System/Library/Frameworks/GLUT.framework/GLUT)
+ if(NOT TARGET GLUT::Cocoa)
+add_library(GLUT::Cocoa UNKNOWN IMPORTED)
+set_target_properties(GLUT::Cocoa PROPERTIES
+ IMPORTED_LOCATION
/System/Library/Frameworks/Cocoa.framework/Cocoa)
+ endif()
+ set_target_properties(GLUT::GLUT PROPERTIES
+INTERFACE_LINK_LIBRARIES GLUT::Cocoa)
+else()
The path to the framework is hard-coded for the include path only
as a possible search location, not as a result. The above code
hard-codes it as a result. FindGLUT is one of the only modules
left that hard-codes -framework XYZ as a result on OS X instead
of allowing find_library to locate the framework. That needs to
be fixed first, and then the framework path can be handled here
the same way as it is in FindOpenGL.
I removed the -framework part and the code now checks if find_library
returned a path to a framework. I also removed the hard-coded path from
the find_library call so this now behaves like most other Find Modules.
diff --git a/Modules/FindGLUT.cmake b/Modules/FindGLUT.cmake
index be7c0cd..9fe8aa0 100644
--- a/Modules/FindGLUT.cmake
+++ b/Modules/FindGLUT.cmake
@@ -2,7 +2,20 @@
# FindGLUT
#
#
-# try to find glut library and include files
+# try to find glut library and include files.
+#
+# IMPORTED Targets
+#
+#
+# This module defines the :prop_tgt:`IMPORTED` targets:
+#
+# ``GLUT::GLUT``
+# Defined if the system has GLUT.
+#
+# Result Variables
+#
+#
+# This module sets the following variables:
#
# ::
#
@@ -42,13 +55,21 @@ if (WIN32)
else ()
if (APPLE)
-# These values for Apple could probably do with improvement.
-find_path( GLUT_INCLUDE_DIR glut.h
- /System/Library/Frameworks/GLUT.framework/Versions/A/Headers
- ${OPENGL_LIBRARY_DIR}
- )
-set(GLUT_glut_LIBRARY -framework GLUT CACHE STRING GLUT library for OSX)
-set(GLUT_cocoa_LIBRARY -framework Cocoa CACHE STRING Cocoa framework for OSX)
+find_path(GLUT_INCLUDE_DIR glut.h ${OPENGL_LIBRARY_DIR})
+find_library(GLUT_glut_LIBRARY GLUT DOC GLUT library for OSX)
+find_library(GLUT_cocoa_LIBRARY Cocoa DOC Cocoa framework for OSX)
+
+if(GLUT_cocoa_LIBRARY AND NOT TARGET GLUT::Cocoa)
+ add_library(GLUT::Cocoa UNKNOWN IMPORTED)
+ # Cocoa should always be a Framework, but we check to make sure.
+ if(GLUT_cocoa_LIBRARY MATCHES /([^/]+)\\.framework$)
+set_target_properties(GLUT::Cocoa PROPERTIES
+ IMPORTED_LOCATION ${GLUT_cocoa_LIBRARY}/${CMAKE_MATCH_1})
+ else()
+set_target_properties(GLUT::Cocoa PROPERTIES
+ IMPORTED_LOCATION ${GLUT_cocoa_LIBRARY})
+ endif()
+endif()
else ()
if (BEOS)
@@ -66,6 +87,18 @@ else ()
/usr/openwin/lib
)
+ if(GLUT_Xi_LIBRARY AND NOT TARGET GLUT::Xi)
+add_library(GLUT::Xi UNKNOWN IMPORTED)
+set_target_properties(GLUT::Xi PROPERTIES
+ IMPORTED_LOCATION ${GLUT_Xi_LIBRARY})
+ endif()
+
+ if(GLUT_Xmu_LIBRARY AND NOT TARGET GLUT::Xmu)
+add_library(GLUT::Xmu UNKNOWN IMPORTED)
+set_target_properties(GLUT::Xmu PROPERTIES
+ IMPORTED_LOCATION ${GLUT_Xmu_LIBRARY})
+ endif()
+
endif ()
find_path( GLUT_INCLUDE_DIR GL/glut.h
@@ -102,6 +135,34 @@ if (GLUT_FOUND)
${GLUT_cocoa_LIBRARY}
)
+ if(NOT TARGET GLUT::GLUT)
+add_library(GLUT::GLUT UNKNOWN IMPORTED)
+set_target_properties(GLUT::GLUT PROPERTIES
+ INTERFACE_INCLUDE_DIRECTORIES ${GLUT_INCLUDE_DIR})
+if(GLUT_glut_LIBRARY MATCHES /([^/]+)\\.framework$)
+ set_target_properties(GLUT::GLUT PROPERTIES
+IMPORTED_LOCATION ${GLUT_glut_LIBRARY}/${CMAKE_MATCH_1})
+else()
+ set_target_properties(GLUT::GLUT PROPERTIES
+IMPORTED_LOCATION ${GLUT_glut_LIBRARY})
+endif()
+
+if(TARGET GLUT::Xmu)
+ set_property(TARGET GLUT::GLUT APPEND
+PROPERTY INTERFACE_LINK_LIBRARIES GLUT::Xmu)
+endif()
+
+if(TARGET GLUT::Xi)
+ set_property(TARGET GLUT::GLUT APPEND
+PROPERTY INTERFACE_LINK_LIBRARIES GLUT::Xi)
+endif()
+
+if(TARGET GLUT::Cocoa)
+ set_property(TARGET GLUT::GLUT APPEND
+PROPERTY INTERFACE_LINK_LIBRARIES GLUT::Cocoa)
+endif()
+ endif()
+
#The following deprecated settings are for backwards compatibility with CMake1.4
set (GLUT_LIBRARY ${GLUT_LIBRARIES})
set (GLUT_INCLUDE_PATH ${GLUT_INCLUDE_DIR})
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
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
Re: [cmake-developers] [PATCH 0/5] IMPORTED targets for some Find modules
On 06/24/2014 08:32 AM, Brad King wrote: I will respond to the individual patch messages for the other two. Thanks for the revisions. I've applied them now as: FindGLUT.cmake: Add imported targets and documentation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=144b255b FindBoost.cmake: Add Boost::boost and Boost::C targets and documentation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=38da974d The transition to a modularized Boost will be tricky and hard to predict so I do not want it to hold back this support now. We can introduce a policy for compatibility later if needed. 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] Weird build error against libc++ on OS X 10.7 (cutting at 1024 characters)
On 06/24/2014 08:31 AM, Mojca Miklavec wrote: /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/CMakeLib.dir/link.txt --verbose=1 isn't outputting the whole command, but cutting it in the middle instead. The lines are read here: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmcmd.cxx;hb=v3.0.0#l988 using the GetLineFromStream helper: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/kwsys/SystemTools.cxx;hb=v3.0.0#l4157 Note the buffer size is 1024. Something must go wrong with the stream state to make it look like EOL or EOF to this code. -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] Weird build error against libc++ on OS X 10.7 (cutting at 1024 characters)
On Tue, Jun 24, 2014 at 14:21:37 -0400, Brad King wrote:
On 06/24/2014 08:31 AM, Mojca Miklavec wrote:
/path/to/cmake-3.0.0/Bootstrap.cmk/cmake -E cmake_link_script
CMakeFiles/CMakeLib.dir/link.txt --verbose=1
isn't outputting the whole command, but cutting it in the middle instead.
The lines are read here:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmcmd.cxx;hb=v3.0.0#l988
using the GetLineFromStream helper:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/kwsys/SystemTools.cxx;hb=v3.0.0#l4157
Note the buffer size is 1024. Something must go wrong with the
stream state to make it look like EOL or EOF to this code.
The proper way to read lines from a file using iostream is:
std::string line;
while (std::getline(istr, line)) {
// use line
}
Unfortunately, it looks like there's unavoidable extra logic in there.
Maybe we could do:
#ifdef BROKEN_STREAMS
// crutch code
#else
// sanity
#endif
--Ben
--
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] Weird build error against libc++ on OS X 10.7 (cutting at 1024 characters)
On Tue, Jun 24, 2014 at 15:23:32 -0400, Brad King wrote: If that actually worked on all old stream libraries then we would not need GetLineFromStream. Also GetLineFromStream has a separate output argument for indicating whether the line ended in a newline. The newline parameter isn't hard to reproduce (just use istr.eof() right after the getline() succeeds), but the sizeLimit parameter is harder :( . We could hack it up with a custom max_size() method on a custom std::basic_string subclass, but that sounds awful. Yes, please try this. Mojca, how did you bootstrap cmake to use libc++ and clang? CXX=clang++ -stdlib=libc++? I probably won't get to it until Thursday though. --Ben -- 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] [CMake 0014989]: cannot build targets 'test' or 'package' after bootstrapping
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14989 == Reported By:Daniel Pfeifer Assigned To: == Project:CMake Issue ID: 14989 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-06-24 16:55 EDT Last Modified: 2014-06-24 16:55 EDT == Summary:cannot build targets 'test' or 'package' after bootstrapping Description: After calling './bootstrap', building the targets 'test' or 'package' fails to find 'ctest' and 'cpack' binaries in directory 'Bootstrap.cmk'. Steps to Reproduce: $ ./bootstrap make $ make test Running tests... make: Bootstrap.cmk/ctest: Command not found Makefile:137: recipe for target 'test' failed make: *** [test] Error 127 $ make package Run CPack packaging tool... make: Bootstrap.cmk/cpack: Command not found Makefile:107: recipe for target 'package' failed make: *** [package] Error 127 == Issue History Date ModifiedUsername FieldChange == 2014-06-24 16:55 Daniel Pfeifer New Issue == -- 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 targets for some Find modules
Philipp Möller wrote:
To simplify exporting targets I added IMPORTED targets to some of the
Find modules.
Thanks for working on this. Just a few minor comments:
In the FindX11 documentation commit, one of the changes is to replace use of
two spaces between sentences with one. That's counter to the prevailing
style in CMake.
cmExportFileGenerator marks frameworks with a FRAMEWORK target property, and
Qt 5 emulates that. It could be done with these files too (I notice in
FindGLUT at least). I don't know if it has any effect on IMPORTED targets,
but it may in the future even if it does not currently.
Is there any reason to make the boost components not depend on each other?
Or is that just left for future development?
The Boost module documents that component imported targets have lower-case
names, but that is not the case (haha). The names depend on the arguments to
find_package currently:
find_package(Boost REQUIRED Thread)
if (TARGET Boost::Thread)
message(YES)
else()
message(NO)
endif()
It looks like a good idea to add Boost::boost to the
INTERFACE_LINK_LIBRARIES of each component imported target, or to similarly
populate the INTERFACE_INCLUDE_DIRECTORIES of each component imported
target.
I would say something similar about the GLUT imported targets, but it seems
that only GLUT::GLUT is documented, so presumably it is the only one
intended for users to use. Is it verified that the other libraries are
really interface dependencies and not runtime requirements? If they are
really interface usage requirements, where are the headers of the other
libraries located?
Multiple IMPORTED_LOCATION_CONFIG are populated on the boost targets, but
the IMPORTED_CONFIGURATIONS target property is not populated.
Is there a need to populate the IMPORTED_IMPLIB_CONFIG target properties
on Windows for any of the targets?
cmExportFileGenerator populates the IMPORTED_LINK_INTERFACE_LANGUAGES target
property, and Qt 5 emulates that. The same could be set to CXX at least for
the Boost targets.
One of the reasons Qt imported targets are called Qt4::Foo and Qt5::Foo is
to avoid accidental combination of, say, Qt::Core and Qt::Gui from different
major versions. They also encode a INTERFACE_QT_MAJOR_VERSION and add
QT_MAJOR_VERSION to the COMPATIBLE_INTERFACE_STRING target property.
Something similar could be added for these imported targets.
In the case of Boost, because they don't provide binary compatibility or
promise source compatibility, it might make sense to encode the full
version, not only the major version, in a similar way to ensure that only
boost libraries from the same boost release are used together. In the
future, post modularization, boost may attempt to release some modules on a
separate release schedule and with disparate version numbers. They may still
release 'boost foobar 1.3' with 'Boost 1.58' though, so '1.58' would still
be the appropriate 'distribution version' to encode.
[Aside: Some people want to release Qt modules with disparate version
schemes too, which has already caused problems:
http://thread.gmane.org/gmane.comp.lib.qt.devel/17144
One of the remaining unsolved problems is that Qt5 packages find their
dependencies with the same version as themselves, so
find_package(Qt5Gui)
which finds a version 5.3.1 Qt5Gui package will call
find_package(Qt5Core 5.3.1)
This obviously would either require mappings to be maintained ('what version
of Qt5 was Enginio 1.0.5/1.2.3 released with?'), or would need to be
dropped. That would be unfortunate because only combinations in the same
'distribution version' (which corresponds to the QtCore version) are tested
together.
But I digress...
]
In the case of boost, it would also make sense to add
INTERFACE_MULTITHREADED to the targets and COMPATIBLE_INTERFACE_BOOL. I'm
assuming that a multithreaded Boost::system can't be used with a non-
multithreaded Boost::filesystem for example. Currently I have the debian
package libboost-thread1.54-dev installed on my system but not the package
libboost-system1.54-dev, so FindBoost will find the thread component but not
the system component (in that prefix at least). Depending on the
build/package of boost it might be possible to conflict on things like that.
Others to consider for this compatibility requirement are the
Boost_COMPILER, Boost_NAMESPACE, Boost_THREADAPI etc.
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
