[Cmake-commits] CMake branch, master, updated. v3.14.0-rc4-327-gf74bb65
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via f74bb6527e669a02ee9f042023fcb4c9cb9f9594 (commit) from 57d178bbca7757792653f1a658423826c52b5730 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f74bb6527e669a02ee9f042023fcb4c9cb9f9594 commit f74bb6527e669a02ee9f042023fcb4c9cb9f9594 Author: Kitware Robot AuthorDate: Wed Mar 13 00:01:07 2019 -0400 Commit: Kitware Robot CommitDate: Wed Mar 13 00:01:07 2019 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index fe45963..2582bf5 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 14) -set(CMake_VERSION_PATCH 20190312) +set(CMake_VERSION_PATCH 20190313) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[CMake] Target not linking to Boost header libs compiled with ExternalProject_Add
Hi all,
I have created a small example app that links to Boost regex (works)
and to a Boost header-only lib property_tree (fails).
Using CMake 3.12.2 on a Ubuntu 18.10 x64, I get this error:
[50%] Building CXX object CMakeFiles/dummy.dir/main.cpp.o
small_superbuild/src/main.cpp:3:10: fatal error:
boost/property_tree/ptree.hpp: No such file or directory
#include
I have used the superbuild pattern to build upstream boost if not
found in the system and finally link to the main app called "dummy".
The idea is from
https://github.com/dev-cafe/cmake-cookbook/tree/master/chapter-08/recipe-02/cxx-example
The folder structure for this dummy project is as follow:
***
CMakeLists.txt
***
cmake_minimum_required(VERSION 3.5)
set( DUMMY_APP_PROJECT_VERSION 0.1
CACHE INTERNAL "Dummy App project version" FORCE)
project(dummy_app VERSION ${DUMMY_APP_PROJECT_VERSION} LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
# Superbuild stuff
set(EP_BASE ${CMAKE_BINARY_DIR}/subprojects)
set_property(DIRECTORY PROPERTY EP_BASE ${EP_BASE})
set(STAGED_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/stage)
include(ExternalProject)
# Add external dependencies
add_subdirectory(external/upstream)
# Dummy App project (main target)
ExternalProject_Add(${PROJECT_NAME}_core
DEPENDS boost_external
SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/src
CMAKE_ARGS -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
-DCMAKE_CXX_STANDARD=${CMAKE_CXX_STANDARD}
-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}
-DCMAKE_CXX_STANDARD_REQUIRED=${CMAKE_CXX_STANDARD_REQUIRED}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_PREFIX_PATH=${CMAKE_PREFIX_PATH}
-DCMAKE_INSTALL_PREFIX=${STAGED_INSTALL_PREFIX}/dummy_app
CMAKE_CACHE_ARGS -DCMAKE_CXX_FLAGS:STRING=${CMAKE_CXX_FLAGS}
-DCMAKE_INCLUDE_PATH:INTERNAL=${BOOST_INCLUDEDIR};${GOOGLETEST_INCLUDEDIR}
-DCMAKE_LIBRARY_PATH:INTERNAL=${BOOST_LIBRARYDIR};${GOOGLETEST_LIBRARYDIR}
-DDUMMY_APP_PROJECT_VERSION:INTERNAL=${DUMMY_APP_PROJECT_VERSION}
-DSTAGED_INSTALL_PREFIX:INTERNAL=${STAGED_INSTALL_PREFIX}
-DBOOST_ROOT:INTERNAL=${BOOST_ROOT}
-DBOOST_INCLUDEDIR:INTERNAL=${BOOST_INCLUDEDIR}
-DBOOST_LIBRARYDIR:INTERNAL=${BOOST_LIBRARYDIR}
-DBOOST_MINIMUM_REQUIRED:INTERNAL=${BOOST_MINIMUM_REQUIRED}
-DBOOST_COMPONENTS_REQUIRED:INTERNAL=${BOOST_COMPONENTS_REQUIRED}
BUILD_ALWAYS 1
)
***
external/upstream/CMakeLists.txt
***
# Boost dependencies
add_subdirectory(boost)
***
external/upstream/boost/CMakeLists.txt
***
set(
BOOST_MINIMUM_REQUIRED "1.65"
CACHE INTERNAL "Minimum Boost version required by the build"
FORCE
)
set(
BOOST_COMPONENTS_REQUIRED regex
CACHE INTERNAL "Boost components required by the build (separated by semicolon)"
FORCE
)
find_package(Boost ${BOOST_MINIMUM_REQUIRED} COMPONENTS
${BOOST_COMPONENTS_REQUIRED})
if(Boost_FOUND)
message(STATUS "Found Boost version
${Boost_MAJOR_VERSION}.${Boost_MINOR_VERSION}.${Boost_SUBMINOR_VERSION}
at the host environment")
add_library(boost_external INTERFACE)
get_filename_component(_boost_root_dir "${Boost_LIBRARY_DIRS}" PATH)
set(
BOOST_ROOT ${_boost_root_dir}
CACHE INTERNAL "Path to externally built Boost installation root"
FORCE
)
set(
BOOST_INCLUDEDIR ${Boost_INCLUDE_DIRS}
CACHE INTERNAL "Path to externally built Boost include directories"
FORCE
)
set(
BOOST_LIBRARYDIR ${Boost_LIBRARY_DIRS}
CACHE INTERNAL "Path to externally built Boost library directories"
FORCE
)
# Unset internal variables
unset(_boost_root_dir)
else()
message(STATUS "Boost ${BOOST_MINIMUM_REQUIRED} could not be located.
Building Boost instead")
if(CMAKE_CXX_COMPILER_ID MATCHES "GNU")
if(APPLE)
set(_toolset "darwin")
else()
set(_toolset "gcc")
endif()
elseif(CMAKE_CXX_COMPILER_ID MATCHES ".*Clang")
set(_toolset "clang")
elseif(CMAKE_CXX_COMPILER_ID MATCHES "Intel")
if(APPLE)
set(_toolset "intel-darwin")
else()
set(_toolset "intel-linux")
endif()
endif()
# Non-empty list. Compiled libraries needed
if(NOT "${BOOST_COMPONENTS_REQUIRED}" STREQUAL "")
# Replace unit_test_framework (used by CMake's find_package) with test
(understood by Boost build toolchain)
string(REPLACE "unit_test_framework" "test" _b2_needed_components
"${BOOST_COMPONENTS_REQUIRED}")
# Generate argument for BUILD_BYPRODUCTS
set(_build_byproducts)
set(_b2_select_libraries)
foreach(_lib IN LISTS _b2_needed_components)
list(APPEND _build_byproducts
${STAGED_INSTALL_PREFIX}/boost/lib/libboost_${_lib}${CMAKE_SHARED_LIBRARY_SUFFIX})
list(APPEND _b2_select_libraries --with-${_lib})
endforeach()
# Transform the ;-separated list to a ,-separated list (digested by
the
Re: [CMake] Correct Boost version found, linked against wrong one
Hey Florian,
Am 12.03.19 um 13:53 schrieb Florian Lindner:
Hello,
I have a simple cmake file for a small project. That project uses boost and
links again a shared lib that also uses boost:
find_library(precice precice PATHS $ENV{PRECICE_ROOT}/build
$ENV{PRECICE_ROOT}/build/last)
find_package(Boost 1.60.0 REQUIRED COMPONENTS system program_options filesystem)
add_executable(preciceMap src/preciceMap.cpp src/common.cpp)
target_include_directories(preciceMap PRIVATE ${Boost_INCLUDE_DIRS})
target_link_libraries(preciceMap ${Boost_LIBRARIES})
target_link_libraries(preciceMap ${precice})
output is:
:~/software/aste/build> cmake ..
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Cray Programming Environment 2.5.17 C
-- Check for working C compiler: /opt/cray/pe/craype/2.5.17/bin/cc
-- Check for working C compiler: /opt/cray/pe/craype/2.5.17/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Cray Programming Environment 2.5.17 CXX
-- Check for working CXX compiler: /opt/cray/pe/craype/2.5.17/bin/CC
-- Check for working CXX compiler: /opt/cray/pe/craype/2.5.17/bin/CC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build configuration: Debug
CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message):
Imported targets not available for Boost version 106600
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
/usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES)
CMakeLists.txt:21 (find_package)
CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message):
Imported targets not available for Boost version 106600
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
/usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES)
CMakeLists.txt:21 (find_package)
CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message):
Imported targets not available for Boost version 106600
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
/usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES)
CMakeLists.txt:21 (find_package)
-- Boost version: 1.66.0
-- Found the following Boost libraries:
-- system
-- program_options
-- filesystem
-- Found MPI_C: /opt/cray/pe/craype/2.5.17/bin/cc
-- Found MPI_CXX: /opt/cray/pe/craype/2.5.17/bin/CC
-- Configuring done
-- Generating done
-- Build files have been written to:
/zhome/academic/HLRS/ipv/ipvflind/software/aste/build
:~/software/aste/build> make
Scanning dependencies of target preciceMap
[ 20%] Building CXX object CMakeFiles/preciceMap.dir/src/preciceMap.cpp.o
[ 40%] Building CXX object CMakeFiles/preciceMap.dir/src/common.cpp.o
[ 60%] Linking CXX executable preciceMap
/usr/bin/ld: warning: libboost_system.so.1.66.0, needed by
/zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so,
may conflict with libboost_system.so.1.54.0
/usr/bin/ld: warning: libboost_filesystem.so.1.66.0, needed by
/zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so,
may conflict with libboost_filesystem.so.1.54.0
/usr/bin/ld: warning: libboost_program_options.so.1.66.0, needed by
/zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so,
may conflict with libboost_program_options.so.1.54.0
/usr/bin/ld: CMakeFiles/preciceMap.dir/src/common.cpp.o: undefined reference to
symbol '_ZN5boost15program_options3argB5cxx11E'
/opt/hlrs/tools/boost/1.66.0/lib/libboost_program_options.so.1.66.0: error
adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
CMakeFiles/preciceMap.dir/build.make:124: recipe for target 'preciceMap' failed
make[2]: *** [preciceMap] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/preciceMap.dir/all'
failed
make[1]: *** [CMakeFiles/preciceMap.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
CMake finds boost 1.66 but why does it try to link against 1.54.0? $BOOST_ROOT
is set and $LIBRARY_PATH, $LD_LIBRARY_PATH and $CPLUS_INCLUDE_PATH are also set
appropriately.
:~/software/aste/build> ls $BOOST_ROOT/lib/*filesystem*
/opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.a
/opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.so
/opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.so.1.66.0
:~/software/aste/build> ls /usr/lib64/*filesystem*
/usr/lib64/libboost_filesystem-mt.so /usr/lib64/libboost_filesystem.so
/usr/lib64/libboost_filesystem.so.1.54.0
Maybe it prefers the -mt variants? But how can I get it to link against the
correct
[CMake] BUG?: ExternalProject_add with CMAKE_COMMAND and Re-run cmake
Hello, I use External_project and set up a cmake subproject that uses au specific CMAKE_COMMAND (a wrapper that does export environment variables) This wrapper is correctly called on first configure but not if CMake decides to rerun CMake at build step. [ 45%] Performing build step for 'lap_project' cd /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/lap/build-debug && /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/make_wrapper_lap.sh gmake[3]: entrant dans le répertoire « /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/lap/build-debug » /appli_MTS/SIP/devtools/cmake/3.8.2/x86_64/Linux/SUSE11.3/bin/cmake -H/appli_RD/LACOSTE/OMEGA/cmakesuperbuild/lap -B/appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/lap/build-debug --check-build-system CMakeFiles/Makefile.cmake 0 Re-run cmake file: Makefile older than: /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/lap/test/CMakeLists.txt My only workaround is to rm the project subdirectory and rerun make (in that case the wrapper is used): [ 50%] Performing configure step for 'lap_project' cd /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/lap/build-debug && /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/cmake_wrapper_lap.sh I tried passing -DCMAKE_COMMAND=mywrapper.sh but it only raise a warning saying that this variable was not used by the project. IMHO it’s a but in ExternalProject_add(). Correct ? Any advice or help is welcome. Regards, XL. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Exporting an imported target not supported?
> We have not thought deeply through the semantics of that in general. > One of the main challenges is relocation handling. Targets installed by the > project have known locations relative to the install prefix and we expect > that everything gets relocated together. Targets from external places have > no such relationship. Sure, this only works in case the locations are known. In my case, extlib is coming from a custom debian package, which locks its location. Another usage scenario could be to actually install (make a copy of) the imported library as it would be compiled from the tree. Not generally a preferable solution but there are some use cases I could think of. > If you're hard-coding paths anyway then I suggest simply linking via absolute > path instead of using an imported target. > If you do need usage requirements, do it through a non-imported interface > library: True, this is a good tip I could consider. My mind was stuck with IMPORTED :) -Lassi -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting an imported target not supported?
On 3/12/19 9:55 AM, Lassi Niemistö wrote: > is there a technical reason why it would not be a good idea to > allow exporting the imported targets with all their properties? We have not thought deeply through the semantics of that in general. One of the main challenges is relocation handling. Targets installed by the project have known locations relative to the install prefix and we expect that everything gets relocated together. Targets from external places have no such relationship. If you're hard-coding paths anyway then I suggest simply linking via absolute path instead of using an imported target. If you do need usage requirements, do it through a non-imported interface library: ``` add_library(extlib INTERFACE) target_link_libraries(extlib INTERFACE /path/to/libextlib.so) target_compile_definitions(extlib INTERFACE ...) ``` That can be installed and exported, and the importing side will simply use the same absolute path. -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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] How can I automatically optionally build a submodule?
Hi, On 12.03.19 06:37, Steve Keller wrote: > How can I build a module in a subdirectory automatically if a required > package is available, but not fail if it's not. Say I have a > top-level CMakeLists.txt with With my Debian Developer hat on: please also add a mechanism to manually specify whether the optional component should be built. If the dependency changes and suddenly a component goes missing without triggering a build failure, that can be rather annoying for users. Without a package system, this also means that old files may stick around after installation, so your program should be aware that installed plugins could be built against an older API and weren't updated during the last install run. Simon signature.asc Description: OpenPGP digital signature -- 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: https://cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v3.14.0-rc4-326-g57d178b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 57d178bbca7757792653f1a658423826c52b5730 (commit) via 5822a7bed289100b78a502e449b436da2fe67af1 (commit) via 05774d4b5845d0b7cbdd1985922b3351a4ebb39d (commit) via 463c2fba4eec7f364689a11b7c36afe966b1f151 (commit) via 21da25d2a878cfccf9496ef7b227de2c98601ef2 (commit) from 7358f317e356dff8ef2c1cdd216b9e6063cd4d9a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=57d178bbca7757792653f1a658423826c52b5730 commit 57d178bbca7757792653f1a658423826c52b5730 Merge: 5822a7b 05774d4 Author: Brad King AuthorDate: Tue Mar 12 13:53:26 2019 + Commit: Kitware Robot CommitDate: Tue Mar 12 09:54:23 2019 -0400 Merge topic 'FindBoost-dyn-link' 05774d4b58 FindBoost: always define BOOST_ALL_DYN_LINK for Boost::dynamic_linking Acked-by: Kitware Robot Merge-request: !3083 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5822a7bed289100b78a502e449b436da2fe67af1 commit 5822a7bed289100b78a502e449b436da2fe67af1 Merge: 7358f31 463c2fb Author: Brad King AuthorDate: Tue Mar 12 13:53:16 2019 + Commit: Kitware Robot CommitDate: Tue Mar 12 09:53:27 2019 -0400 Merge topic 'shell_path' 463c2fba4e Genex: Teach SHELL_PATH to support a list of paths 21da25d2a8 Tests: Generalize GeneratorExpression MSYS path conversion workaround Acked-by: Kitware Robot Merge-request: !3057 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=05774d4b5845d0b7cbdd1985922b3351a4ebb39d commit 05774d4b5845d0b7cbdd1985922b3351a4ebb39d Author: NeroBurner AuthorDate: Mon Mar 11 03:48:20 2019 -0400 Commit: Brad King CommitDate: Mon Mar 11 13:24:51 2019 -0400 FindBoost: always define BOOST_ALL_DYN_LINK for Boost::dynamic_linking The purpose of the `Boost::dynamic_linking` interface library is to cause `BOOST_ALL_DYN_LINK` to be defined. Do this on all platforms instead of just Windows. In particular, using Boost::log trivial_logger requires to set BOOST_ALL_NO_LIB when Boost::Log is compiled as dynamic library. Fixes: #17813 diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake index 7882c4b..6e7d3db 100644 --- a/Modules/FindBoost.cmake +++ b/Modules/FindBoost.cmake @@ -1201,6 +1201,8 @@ if(NOT TARGET Boost::diagnostic_definitions) add_library(Boost::diagnostic_definitions INTERFACE IMPORTED) add_library(Boost::disable_autolinking INTERFACE IMPORTED) add_library(Boost::dynamic_linking INTERFACE IMPORTED) + set_target_properties(Boost::dynamic_linking PROPERTIES +INTERFACE_COMPILE_DEFINITIONS "BOOST_ALL_DYN_LINK") endif() if(WIN32) # In windows, automatic linking is performed, so you do not have @@ -1225,8 +1227,6 @@ if(WIN32) INTERFACE_COMPILE_DEFINITIONS "BOOST_LIB_DIAGNOSTIC") set_target_properties(Boost::disable_autolinking PROPERTIES INTERFACE_COMPILE_DEFINITIONS "BOOST_ALL_NO_LIB") - set_target_properties(Boost::dynamic_linking PROPERTIES -INTERFACE_COMPILE_DEFINITIONS "BOOST_ALL_DYN_LINK") endif() _Boost_CHECK_SPELLING(Boost_ROOT) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=463c2fba4eec7f364689a11b7c36afe966b1f151 commit 463c2fba4eec7f364689a11b7c36afe966b1f151 Author: Henri Manson AuthorDate: Mon Mar 4 12:40:24 2019 +0100 Commit: Brad King CommitDate: Mon Mar 11 11:39:25 2019 -0400 Genex: Teach SHELL_PATH to support a list of paths Extend the genex added by commit ca6ba3fee5 (Genex: Add a SHELL_PATH expression, 2015-09-24, v3.4.0-rc1~37^2) to accept a `;`-list of paths, convert them all, and generate a list separated by the native shell `PATH``` separator. diff --git a/Help/manual/cmake-generator-expressions.7.rst b/Help/manual/cmake-generator-expressions.7.rst index 7f484a4..614358a 100644 --- a/Help/manual/cmake-generator-expressions.7.rst +++ b/Help/manual/cmake-generator-expressions.7.rst @@ -455,6 +455,11 @@ Output-Related Expressions Content of ``...`` converted to shell path style. For example, slashes are converted to backslashes in Windows shells and drive letters are converted to posix paths in MSYS shells. The ``...`` must be an absolute path. + The ``...`` may be a :ref:`semicolon-separated list ` + of paths, in which case each path is converted individually and a result + list is generated using the shell path separator (``:`` on POSIX and + ``;`` on Windows). Be sure to enclose the argument containing this genex + in double quotes in CMake source code so that ``;`` does not split arguments. Debugging
Re: [cmake-developers] Exporting an imported target not supported?
> The file `cmake_test_system_lassi/tree1/Tree1Config.cmake` should have code > to re-create the extlib imported target > with whatever usage requirements it had for building tree1. See the patch > below. > In combination with removing all the `extlib_interface` code, the `test.sh` > script passes. > Generally imported targets are not manually created by project code. > Instead they come from `find_package(MyDependency)`. Tree1Config should > repeat `find_package(MyDependency)` for > public-facing dependencies. If you don't want to create a complete find > module for extlib, you can create a normal > module that gets `include()`d from both places. I see. In my case extlib is really an external lib which does not provide any cmake helpers (finder modules / configs) so I need to write them myself. I wish to totally hide the need of extlib from tree2 perspective and not call its finders there. Actually, I would like to not care about it even at the point of exporting mylib, as extlib is a tiny tiny sub-sub-dependency of mylib. I would like to do this via modern target base cmake approach together with export mechanisms. Needing to also provide parts of my tree1 cmake code for tree2 kind of breaks this abstraction. Just being able to export all the imported targets as well would be cool, but seems that the workaround I did is actually pretty close. Posted an iterated version https://gitlab.com/lassi.niemisto/cmake_import_case/commit/9f6a26284835ab272dcc8acd5bfde144e73fafe8 Thanks for all the rubberducking! I think this solution suffices. Just one more question: is there a technical reason why it would not be a good idea to allow exporting the imported targets with all their properties? -Lassi -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] Why do we need NVIDIA Nsight Tegrato create Visual Studio Android Projects?
We would like to use Xamarin for our x-platform app-development with VS. Is any support for that planned in the near future? Am 11.03.2019 um 15:30 schrieb Daniel Wynne: Hi All! Short question: why do we need NVIDIA Nsight Tegra to setup a Visual Studio Android project? Despite of it being a helpful tool, the necessity for it to create the project file is unclear to me. Could you please enlighten me? Kind Regards Daniel -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Exporting an imported target not supported?
On 3/12/19 6:57 AM, Lassi Niemistö wrote:
> What to do in order to get rid of the extlib_interface workaround?
> I have not yet seen any means of "exporting" the properties of an
> imported target to tree2.
The file `cmake_test_system_lassi/tree1/Tree1Config.cmake` should
have code to re-create the extlib imported target with whatever
usage requirements it had for building tree1. See the patch below.
In combination with removing all the `extlib_interface` code, the
`test.sh` script passes.
Generally imported targets are not manually created by project code.
Instead they come from `find_package(MyDependency)`. Tree1Config
should repeat `find_package(MyDependency)` for public-facing
dependencies. If you don't want to create a complete find module
for extlib, you can create a normal module that gets `include()`d
from both places.
See the docs here:
https://cmake.org/cmake/help/v3.14/manual/cmake-packages.7.html#creating-a-package-configuration-file
-Brad
```
diff --git a/cmake_test_system_lassi/tree1/Tree1Config.cmake
b/cmake_test_system_lassi/tree1/Tree1Config.cmake
index 45f31f3..65248f3 100644
--- a/cmake_test_system_lassi/tree1/Tree1Config.cmake
+++ b/cmake_test_system_lassi/tree1/Tree1Config.cmake
@@ -1 +1,4 @@
+add_library(extlib SHARED IMPORTED)
+set_target_properties(extlib PROPERTIES IMPORTED_LOCATION
/tmp/cmake_test_system_lassi/extlib/build/libextlib.so)
+target_include_directories(extlib INTERFACE
/tmp/cmake_test_system_lassi/extlib/)
include("${CMAKE_CURRENT_LIST_DIR}/Tree1Targets.cmake")
```
--
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:
https://cmake.org/mailman/listinfo/cmake-developers
[CMake] Correct Boost version found, linked against wrong one
Hello,
I have a simple cmake file for a small project. That project uses boost and
links again a shared lib that also uses boost:
find_library(precice precice PATHS $ENV{PRECICE_ROOT}/build
$ENV{PRECICE_ROOT}/build/last)
find_package(Boost 1.60.0 REQUIRED COMPONENTS system program_options filesystem)
add_executable(preciceMap src/preciceMap.cpp src/common.cpp)
target_include_directories(preciceMap PRIVATE ${Boost_INCLUDE_DIRS})
target_link_libraries(preciceMap ${Boost_LIBRARIES})
target_link_libraries(preciceMap ${precice})
output is:
:~/software/aste/build> cmake ..
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Cray Programming Environment 2.5.17 C
-- Check for working C compiler: /opt/cray/pe/craype/2.5.17/bin/cc
-- Check for working C compiler: /opt/cray/pe/craype/2.5.17/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Cray Programming Environment 2.5.17 CXX
-- Check for working CXX compiler: /opt/cray/pe/craype/2.5.17/bin/CC
-- Check for working CXX compiler: /opt/cray/pe/craype/2.5.17/bin/CC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build configuration: Debug
CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message):
Imported targets not available for Boost version 106600
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
/usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES)
CMakeLists.txt:21 (find_package)
CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message):
Imported targets not available for Boost version 106600
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
/usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES)
CMakeLists.txt:21 (find_package)
CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message):
Imported targets not available for Boost version 106600
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
/usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES)
CMakeLists.txt:21 (find_package)
-- Boost version: 1.66.0
-- Found the following Boost libraries:
-- system
-- program_options
-- filesystem
-- Found MPI_C: /opt/cray/pe/craype/2.5.17/bin/cc
-- Found MPI_CXX: /opt/cray/pe/craype/2.5.17/bin/CC
-- Configuring done
-- Generating done
-- Build files have been written to:
/zhome/academic/HLRS/ipv/ipvflind/software/aste/build
:~/software/aste/build> make
Scanning dependencies of target preciceMap
[ 20%] Building CXX object CMakeFiles/preciceMap.dir/src/preciceMap.cpp.o
[ 40%] Building CXX object CMakeFiles/preciceMap.dir/src/common.cpp.o
[ 60%] Linking CXX executable preciceMap
/usr/bin/ld: warning: libboost_system.so.1.66.0, needed by
/zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so,
may conflict with libboost_system.so.1.54.0
/usr/bin/ld: warning: libboost_filesystem.so.1.66.0, needed by
/zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so,
may conflict with libboost_filesystem.so.1.54.0
/usr/bin/ld: warning: libboost_program_options.so.1.66.0, needed by
/zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so,
may conflict with libboost_program_options.so.1.54.0
/usr/bin/ld: CMakeFiles/preciceMap.dir/src/common.cpp.o: undefined reference to
symbol '_ZN5boost15program_options3argB5cxx11E'
/opt/hlrs/tools/boost/1.66.0/lib/libboost_program_options.so.1.66.0: error
adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
CMakeFiles/preciceMap.dir/build.make:124: recipe for target 'preciceMap' failed
make[2]: *** [preciceMap] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/preciceMap.dir/all'
failed
make[1]: *** [CMakeFiles/preciceMap.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
CMake finds boost 1.66 but why does it try to link against 1.54.0? $BOOST_ROOT
is set and $LIBRARY_PATH, $LD_LIBRARY_PATH and $CPLUS_INCLUDE_PATH are also set
appropriately.
:~/software/aste/build> ls $BOOST_ROOT/lib/*filesystem*
/opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.a
/opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.so
/opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.so.1.66.0
:~/software/aste/build> ls /usr/lib64/*filesystem*
/usr/lib64/libboost_filesystem-mt.so /usr/lib64/libboost_filesystem.so
/usr/lib64/libboost_filesystem.so.1.54.0
Maybe it prefers the -mt variants? But how can I get it to link against the
correct files, i.e., 1.66?
Or is the "DSO missing from command line" another
Re: [CMake] Invalid escape sequence in macro
Thank you, Steph
This might be related. I think the macro somehow resolves the escapes before
executing the marco commands.
Today I found out, this error is much worse in a project (instead of a script).
Please see the updated code (now we escape correctly at declaration):
function(f STRING)
message(STATUS "In function: ${STRING}")
endfunction()
macro(m STRING)
message(STATUS "In macro: ${STRING}")
endmacro()
set(CONTENT "bla bla \\/\\/")
message(STATUS "No call1: ${CONTENT}")
f(${CONTENT})
m(${CONTENT})
message(STATUS "No call2: ${CONTENT}")
Output:
C:\Program Files\CMake\cmake-3.13.4-win64-x64\bin>cmake -P test.cmake
-- No call1: bla bla \/\/
-- In function: bla bla \/\/
CMake Warning (dev) at test.cmake:6 (message):
Syntax error in cmake code at
C:/Program Files/CMake/cmake-3.13.4-win64-x64/bin/test.cmake:6
when parsing string
In macro: bla bla \/\/
Invalid escape sequence \/
Policy CMP0010 is not set: Bad variable reference syntax is an error. Run
"cmake --help-policy CMP0010" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
Call Stack (most recent call first):
test.cmake:12 (m)
This warning is for project developers. Use -Wno-dev to suppress it.
-- In macro: bla bla \/\/
-- No call2: bla bla \/\/
Tthis gets way worse when it is a project:
project(testEscape)
cmake_minimum_required(VERSION 3.10)
...
The error is not reported. Silently the string is modified and printed wrongly!
C:\Program Files\CMake>cmake-3.13.4-win64-x64\bin\cmake.exe . -Bbuild313
-- Building for: Visual Studio 14 2015
-- The C compiler identification is MSVC 19.0.23918.0
-- The CXX compiler identification is MSVC 19.0.23918.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio
14.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio
14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 14.0/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 14.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- No call1: bla bla \/\/
-- In function: bla bla \/\/
-- In macro: bla bla //
-- No call2: bla bla \/\/
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Program Files/CMake/build313
Note that previous policies stopped configuration. Change
cmake_minimum_required(VERSION 3.0)
And you get:
...
-- No call1: bla bla \&
-- In function: bla bla \&
CMake Error at CMakeLists.txt:9 (message):
Syntax error in cmake code at
C:/Program Files/CMake/CMakeLists.txt:9
when parsing string
In macro: bla bla \&
Invalid escape sequence \&
Call Stack (most recent call first):
CMakeLists.txt:15 (m)
-- Configuring incomplete, errors occurred!
Regards,
Felix
-Ursprüngliche Nachricht-
Von: stephan.sz...@sony.com [mailto:stephan.sz...@sony.com]
Gesendet: Montag, 11. März 2019 17:28
An: Ramold, Felix; cmake@cmake.org
Betreff: RE: Invalid escape sequence in macro
I would expect that you're running into a consequence of:
"In a function, ARGN, ARGC, ARGV and ARGV0, ARGV1, ... are true variables in
the usual CMake sense. In a macro, they are not, they are string replacements
much like the C preprocessor would do with a macro."
So I would expect the backslash escapes are done first on the set line, and
then the value of the variable after the escaping are replaced into the message
line in the macro which will then try to handle escapes again.
It seems like a function may be better for this sort of thing, but what does
the actual use case look like?
Regards,
Steph
-Original Message-
From: CMake On Behalf Of Ramold, Felix
Sent: Monday, March 11, 2019 8:20 AM
To: cmake@cmake.org
Subject: [CMake] Invalid escape sequence in macro
Hi,
today i ran into an error with escape characters in macros. Is this a known
issue? Is this by design? How can I workaround?
Code:
function(f STRING)
message(STATUS ${STRING})
endfunction()
macro(m STRING)
message(STATUS ${STRING})
endmacro()
set(CONTENT "bla bla \/\/")
message(STATUS ${CONTENT})
f(${CONTENT})
m(${CONTENT})
Output:
ramold@xxx MINGW64 /c/Program Files/CMake/cmake-3.13.4-win64-x64/bin
$ ./cmake.exe -P test.cmake
CMake Warning (dev) at test.cmake:9 (set):
Syntax error in cmake code at
C:/Program Files/CMake/cmake-3.13.4-win64-x64/bin/test.cmake:9
when parsing string
bla bla \/\/
Invalid escape sequence \/
Policy CMP0010 is not set: Bad variable reference syntax is an error. Run
"cmake --help-policy CMP0010" for policy details. Use the cmake_policy
command to set the policy and suppress
Re: [CMake] How can I automatically optionally build a submodule?
On 12.03.2019 06:37 Steve Keller wrote: How can I build a module in a subdirectory automatically if a required package is available, but not fail if it's not. Say I have a top-level CMakeLists.txt with add_subdirectory(foo) add_subdirectory(bar) and in directory foo I have in CMakeLists.txt find_package(yadda, REQUIRED) I want the submodule foo to be build automatically if the package yadda is found. Otherwise, foo should be left out and the top-level build should not fail but continue. If you want yadda to be optional then don't use REQUIRED. find_package(yadda) if (yadda_FOUND) message(STATUS "found yadda, building bar ...") # add your code to build bar here endif () This should do what you want - unless I misunderstood your question. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] further configuration of generated projects outside of CMake?
Oh, I see now. The generator only adds the project files and the rest of the build output remains exactly the same with or without a generator. So I only use the generator once. Folders and libraries are not added in Eclipse GUI but rather in CMake project as you'd normally do. The project is already configured for the standard build targets normally used. If I had a new build target at some point, like `make doxygen` I'd probably edit the project manually and add it. On 12/03/19 03:00, Zan Lynx wrote: On March 11, 2019 6:03:24 PM MDT, hex wrote: hi everyone, There are many generators supported in CMake. A CMake build system allows me to generate the preferred build environment for everyone, visual studio, eclipse, ninja you name it. The problem I see with this is that projects are generated output files, and even if that gives everyone the starting point in the way he/she is used to, they will probably want to further customize their project preferences. But every build folder, every library that is added to the project sources later on in CMake must be reflected in those projects as well. This means any customizations done outside of CMake is lost. You don't ship the generated files with the source. Everyone runs cmake for themselves. And if you did ship some, like a Makefile, you would not customize that any more than you'd customize it from an autoconf project. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Exporting an imported target not supported?
> Please post a minimal example tarball showing your case in practice. https://gitlab.com/lassi.niemisto/cmake_import_case Instruction: * run the test.sh script, it will copy the test setup under /tmp/ and operate it there * by default everything should pass * go to cmake_test_system_lassi/tree1/CMakeLists.txt and comment out the line 25 * now running test.sh again fails Realizations during creating the minimal setup: * Talks about not being able to export library linked to an IMPORTED library in INTERFACE mode were bullcrap, sorry. I had still a secondary build mode enabled which created "extlib" in-tree as a regular library, which created this uninteresting "not in export set" error. So: exporting a library with IMPORTED dependencies is fine to CMake. * I understood that the -rpath-link is probably not what I want. It would help in case extlib was PRIVATE linked by mylib. But since PRIVATE linking would stop any properties of extlib to be inherited by mylib's users, it won't work. PUBLIC linking instead makes users of mylib to also link to extlib, which again benefits from target_link_directories, not -rpath-link. Bottom line question: What to do in order to get rid of the extlib_interface workaround? I have not yet seen any means of "exporting" the properties of an imported target to tree2. Thanks, -Lassi -- 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: https://cmake.org/mailman/listinfo/cmake-developers
