From sramnath at axon.com Fri Dec 6 13:17:55 2019 From: sramnath at axon.com (samyuktar) Date: Fri, 6 Dec 2019 11:17:55 -0700 (MST) Subject: [CMake] CMakeLists.txt : Link options not working properly Message-ID: <1575656275722-0.post@n2.nabble.com> Hello, I am using the TI-CGT compiler and have been successful in getting all my source files to compile. However, I am unable to get the link command to successfully link, and I have crafted a manual link command which I have to then manually enter into the terminal once the build compiles all the files and fails at the link stage. I derived the link command from Code Composer Studio and took guidance for what libraries are missing. However when I tried to add this to the target_link_libraries in CMake, that didn't work. Here is my manual link command: "/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/bin/armcl" -mv7M4 --code_state=16 --float_support=FPv4SPD16 -me --define=DeviceFamily_CC13X2 -g --diag_warning=225 --diag_warning=255 --diag_wrap=off --display_error_number --gen_func_subsections=on -z -m"lwipthreads_CC1352P1_LAUNCHXL_tirtos_ccs.map" -i"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source" -i"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/kernel/tirtos/packages" -i"/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib" --diag_wrap=off --display_error_number --warn_sections --xml_link_info="lwipthreads_CC1352P1_LAUNCHXL_tirtos_ccs_linkInfo.xml" --rom_model --output_file="lwipthreads_CC1352P1_LAUNCHXL_tirtos_ccs.out" "CMakeFiles/test.out.dir/main_tirtos.c.obj" "../CC1352P1_LAUNCHXL_TIRTOS.cmd" -l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source/ti/grlib/lib/ccs/m4f/grlib.a" -lliblwipcontribapps.a -lliblwipboard.a -lliblwipcore.a -lliblwipcontribporttirtos.a -l"ti/display/lib/display.aem4f" -l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source/third_party/spiffs/lib/ccs/m4f/spiffs_cc26xx.a" -l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source/ti/drivers/rf/lib/rf_multiMode_cc13x2.aem4f" -l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source/ti/drivers/lib/drivers_cc13x2.aem4f" -l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/kernel/tirtos/packages/ti/dpl/lib/dpl_cc13x2.aem4f" -l"../linker.cmd" -l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source/ti/devices/cc13x2_cc26x2/driverlib/bin/ccs/driverlib.lib" -llibc.a Here, liblwipcore.a, liblwipcontribporttirtos.a, liblwipboard.a, liblwipcontribapps.a, are libraries that I have made using my CMakeLists.txt. The rest are standard libraries coming from TI's SDK. The other thing is that I am unable to add the ../CC1352P1_LAUNCHXL_TIRTOS.cmd in the CMakeLists.txt the way that I need it in the linker command that I added above. This file has some information about sections for .data, .code, .bss, flash memory partitions and the system memory map etc. so it is definitely required by the CC1352P1 board to be able to run this on the board. Here is what I have in CMakeLists.txt for the link step : set( cc1352p1_libs ${TIRTOS_SDK}/source/ti/display/lib/display.aem4f ${TIRTOS_SDK}/source/ti/grlib/lib/ccs/m4f/grlib.a ${TIRTOS_SDK}/source/third_party/spiffs/lib/ccs/m4f/spiffs_cc26xx.a ${TIRTOS_SDK}/source/ti/drivers/rf/lib/rf_multiMode_cc13x2.aem4f ${TIRTOS_SDK}/source/ti/drivers/lib/drivers_cc13x2.aem4f ${TIRTOS_SDK}/kernel/tirtos/packages/ti/dpl/lib/dpl_cc13x2.aem4f ${TIRTOS_SDK}/source/ti/devices/cc13x2_cc26x2/driverlib/bin/ccs/driverlib.lib # ${TIRTOS_SDK}/source/third_party/fatfs/lib/ccs/m4/fatfs.a /Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib/rtsv7M4_T_le_v4SPD16_eabi.lib ${LWIP_DIR}/linker.cmd ) set( cc1352p1_lib_dirs ${TIRTOS_SDK}/source/ti/display/lib ${TIRTOS_SDK}/source/ti/grlib/lib/ccs/m4f ${TIRTOS_SDK}/source/third_party/spiffs/lib/ccs/m4f ${TIRTOS_SDK}/source/ti/drivers/rf/lib ${TIRTOS_SDK}/source/ti/drivers/lib ${TIRTOS_SDK}/kernel/tirtos/packages/ti/dpl/lib ${TIRTOS_SDK}/source/ti/devices/cc13x2_cc26x2/driverlib/bin/ccs ${TIRTOS_SDK}/source/third_party/fatfs/lib/ccs/m4 /Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib ) add_link_options(test.out ../CC1352P1_LAUNCHXL_TIRTOS.cmd) target_link_libraries(test.out lwipcontribapps lwipboard lwipcontribporttirtos lwipcontribexamples lwipcore ${CMAKE_COMPILER_PATH}/lib/libc.a ${cc1352p1_libs}) add_definitions( ${LWIP_COMPILE_OPTIONS}) # ${LWIP_BIOS_OPTS} ) Here's the error that I get when I say make: >> WARNING: invalid linker option >> --warn_sections--xml_link_info=gpiointerrupt_CC1352P1_LAUNCHXL_tirtos_ccs_linkInfo.xml >> (ignored) error #10056: symbol "free" redefined: first defined in "/Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_L AUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f"; redefined in "/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib/rt sv7M4_T_le_v4SPD16_eabi.lib" error #10056: symbol "realloc" redefined: first defined in "/Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_L AUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f"; redefined in "/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib/rt sv7M4_T_le_v4SPD16_eabi.lib" error #10056: symbol "memalign" redefined: first defined in "/Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_L AUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f"; redefined in "/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib/rt sv7M4_T_le_v4SPD16_eabi.lib" error #10056: symbol "calloc" redefined: first defined in "/Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_L AUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f"; redefined in "/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib/rt sv7M4_T_le_v4SPD16_eabi.lib" error #10056: symbol "malloc" redefined: first defined in "/Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_L AUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f"; redefined in "/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib/rt sv7M4_T_le_v4SPD16_eabi.lib" "../linker.cmd", line 646: warning #10096-D: specified address lies outside memory map error #10264: DEFAULT memory range overlaps existing memory range RAM undefined first referenced symbol in file --------- ---------------- __aeabi_cdcmple /Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_LAUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f __aeabi_cdrcmple /Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_LAUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f __aeabi_d2iz /Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_LAUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f __aeabi_d2uiz /Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_LAUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f __aeabi_dmul /Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_LAUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f __aeabi_dsub /Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_LAUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f __aeabi_f2d /Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_LAUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f __aeabi_i2d /Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_LAUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f __aeabi_uidivmod /Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_LAUNCHXL_release_ccs/src/sysbios/rom_sysbios.aem4f __primary_heap_end__ /Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_LAUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f __primary_heap_start__ /Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_LAUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f sys_init liblwipcore.a sys_mbox_trypost liblwipcore.a sys_mbox_valid liblwipcore.a sys_now liblwipcore.a error #10234-D: unresolved symbols remain error #10010: errors encountered during linking; "test.out" not built These errors are all resolved when I manually enter the above linker command. Please help me out with the link step of the CMake command. -- Sent from: http://cmake.3232098.n2.nabble.com/ From robert.maynard at kitware.com Tue Dec 10 13:00:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 10 Dec 2019 13:00:00 -0500 Subject: [CMake] ANNOUNCE] CMake 3.16.1 available for download Message-ID: We are pleased to announce that CMake 3.16.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.16.1 since 3.16.0: Alexander Grund (2): bootstrap: Add target_link_options command Check for support before adding bigtoc linker flag Ben Boeckel (1): TestDriver: ignore strcpy call Brad King (2): FindThreads: Restore hard-coded '-l' flag on library name CMake 3.16.1 Cristian Adam (5): PCH: Do not add #pragma system_header for Xcode generator Unity/PCH: Skip more target types when adding automatic sources Unity: Generic source file handling for all generators Unity: Proper handling of object libraries PCH: Use the target's PREFIX for building the pdb file name Kyle Edwards (1): CTest Resource Allocation: Add test for spec file with no version Tobias Taschner (1): FindwxWidgets: Add support for 3.1.3 on macOS From federico.kircheis at gmail.com Wed Dec 11 06:23:34 2019 From: federico.kircheis at gmail.com (Federico Kircheis) Date: Wed, 11 Dec 2019 12:23:34 +0100 Subject: [CMake] CMake on host executing compiler inside docker Message-ID: Hello, I'm trying to solve following problem. test as many different compilers as possible with no (or minimal) maintenance burden. As docker is the newest trend, I decided to give it a try (nearly using it for the first time). Also the GCC team has official docker images (https://hub.docker.com/_/gcc/), so I decided to give it a try. The main advantage is that I do not need to manage, compile and package myself all different compiler versions for my operating system. The issue is that the integration between tools inside docker images and tools outside docker images is very bad. I do not want to install CMake (and other tools) on those images as I could see on many projects because * it does not scale at all if I want to also test different version of CMake, make, ninja, clang, ... * It's a maintenance burden, as every time the base image gets updated, I need to update my modified images too * If I modify the official image, I need to know internal details that are not really relevant for testing the compiler (what OS, package manager, directory structure, ...) * It does not solve the integration issue, I do not think that installing the whole IDE would be a good idea. At that point, compiling and packaging for the host platform is probably easier. So what I tried was to take the docker images, and let my local CMake (CMake on the host, not in docker), use the compiler in the docker image. This would have following advantages * compiler and build system are decoupled, I can easily test many version combinations of the two * No need to know how the image is build, I'm using it as a black box, as originally intended. * As most IDE understand make or CMake, I have the integration with the dockerized compiler for free (probably for other tools too) I've created following toolchain file ---- set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_CROSSCOMPILING TRUE) # FIXME: instead of hard coding 1000, map for real user id... # Good enough for now as generated files are not owned by root set(command "docker;run;--env;VERBOSE=1;-v;${CMAKE_SOURCE_DIR}:${CMAKE_SOURCE_DIR};-w;${CMAKE_SOURCE_DIR};--user;1000;gcc:5") foreach(LANG C CXX ASM) set(CMAKE_${LANG}_COMPILER_LAUNCHER ${command} CACHE STRING "") endforeach() #set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "docker run --env VERBOSE=1 -v ${CMAKE_SOURCE_DIR}:${CMAKE_SOURCE_DIR} -w ${CMAKE_SOURCE_DIR} --user 1000 gcc:5") set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) ---- (the second attempt was setting `set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "docker run --env VERBOSE=1 -v ${CMAKE_SOURCE_DIR}:${CMAKE_SOURCE_DIR} -w ${CMAKE_SOURCE_DIR} --user 1000 gcc:5")`, but it did not make any difference) and used it like ---- m -rf build;cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=toolchain-docker.cmake --debug-trycompile && cmake --build build ---- I can see that the makefiles all have "docker run ...." commands, which looks great, but CMake, in it's internal logic, does not seem to always apply the `RULE_LAUNCH_COMPILE` and `CMAKE_${LANG}_COMPILER_LAUNCHER`, as the output looks like: ---- -- The C compiler identification is GNU 9.2.1 -- The ASM compiler identification is GNU -- Found assembler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works ---- GCC 9.2.1 is the compiler on my local host, the output should have been version 5. I've also noticed that internal tests, like /usr/share/cmake-3.13/Modules/CMakeTestCCompiler.cmake:52, gets executed with the "docker run" prefix, and they do not fail. Is there some parameter that I'm missing, or is there a better way to achieve what I'm trying to do? I can also verify that CMake does not always apply "RULE_LAUNCH_COMPILE" and "CMAKE_${LANG}_COMPILER_LAUNCHER", because if I add "set(CMAKE_C_COMPILER /usr/local/bin/gcc)" (which is the internal path in docker), then CMake prints ---- -- The C compiler identification is unknown -- The ASM compiler identification is unknown -- Didn't find assembler CMake Error at CMakeLists.txt:12 (project): The CMAKE_C_COMPILER: /usr/local/bin/gcc is not a full path to an existing compiler tool. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. ---- as GCC on my host is "/usr/bin/gcc". From rjvbertin at gmail.com Thu Dec 12 09:15:20 2019 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 12 Dec 2019 15:15:20 +0100 Subject: [CMake] building cmake without the bootstrap step Message-ID: <2500020.t0S6ugJn35@bola> Hi, If I understand correctly, configuring CMake for building means bootstrapping a basic version of itself which is then run on the included CMakeLists.txt file. That takes a lot of time (comparatively) which begs the question if there's a more-of-less official way to skip the bootstrap and just use the installed cmake binary? Thanks, Ren? From kyle.edwards at kitware.com Thu Dec 12 09:36:03 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 12 Dec 2019 09:36:03 -0500 Subject: [CMake] building cmake without the bootstrap step In-Reply-To: <2500020.t0S6ugJn35@bola> References: <2500020.t0S6ugJn35@bola> Message-ID: <1576161363.3628.1.camel@kitware.com> On Thu, 2019-12-12 at 15:15 +0100, Ren? J.V. Bertin wrote: > Hi, > > If I understand correctly, configuring CMake for building means > bootstrapping a basic version of itself which is then run on the > included CMakeLists.txt file. That takes a lot of time > (comparatively) which begs the question if there's a more-of-less > official way to skip the bootstrap and just use the installed cmake > binary? The bootstrap CMake does not have all of the capabilities of the real CMake - just enough to build CMake itself. It is intended to be used once to build the real CMake and then immediately discarded. If you want to skip bootstrapping, you can use a pre-existing CMake binary for your system to build the new CMake. This mailing list is deprecated. Please head over to Discourse for further discussion: https://discourse.cmake.org/c/usage Kyle From rjvbertin at gmail.com Thu Dec 12 12:55:24 2019 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 12 Dec 2019 18:55:24 +0100 Subject: [CMake] building cmake without the bootstrap step In-Reply-To: <1576161363.3628.1.camel@kitware.com> References: <2500020.t0S6ugJn35@bola> <1576161363.3628.1.camel@kitware.com> Message-ID: <4054003.NGNdq1Tp9a@bola> On Thursday December 12 2019 09:36:03 Kyle Edwards wrote: >If you want to skip bootstrapping, you can use a pre-existing CMake >binary for your system to build the new CMake. > >This mailing list is deprecated. Please head over to Discourse for >further discussion: OK, thanks. To finish things up here, there is thus nothing in the arguments to the bootstrap script that is crucial and cannot be set via a preexisting cmake command? R. From rjvbertin at gmail.com Thu Dec 12 13:20:36 2019 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 12 Dec 2019 19:20:36 +0100 Subject: [CMake] building cmake without the bootstrap step In-Reply-To: <4054003.NGNdq1Tp9a@bola> References: <2500020.t0S6ugJn35@bola> <1576161363.3628.1.camel@kitware.com> <4054003.NGNdq1Tp9a@bola> Message-ID: <22845257.YVJrfeebTh@bola> Never mind, this tweak to the bootstrap script should take care of anything not directly obvious. Could do with an automated test of the installed version but the accepted version range is so large that doesn't seem to be the trouble. ``` if [ -x ${cmake_prefix_dir}/bin/cmake ] ;then # use the existing cmake that we'll be replacing. ln -s ${cmake_prefix_dir}/bin/cmake ${cmake_bootstrap_dir}/cmake else # Run make to build bootstrap cmake if [ "x${cmake_parallel_make}" != "x" ]; then ${cmake_make_processor} ${cmake_make_flags} else ${cmake_make_processor} fi RES=$? if [ "${RES}" -ne "0" ]; then cmake_error 9 "Problem while running ${cmake_make_processor}" fi fi cd "${cmake_binary_dir}" ``` R From baschdel_98 at web.de Fri Dec 13 02:34:23 2019 From: baschdel_98 at web.de (baschdel_98 at web.de) Date: Fri, 13 Dec 2019 08:34:23 +0100 Subject: [CMake] Cpack with Bundleutilities on Windows Message-ID: An HTML attachment was scrubbed... URL: From baschdel_98 at web.de Mon Dec 16 05:37:34 2019 From: baschdel_98 at web.de (baschdel_98 at web.de) Date: Mon, 16 Dec 2019 11:37:34 +0100 Subject: [CMake] (no subject) Message-ID: An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Dec 16 15:42:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 16 Dec 2019 15:42:00 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.15.6 available for download Message-ID: We are pleased to announce that CMake 3.15.6 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.15.6 since 3.15.5: Alexander Grund (1): Check for support before adding bigtoc linker flag Ben Boeckel (1): FindPostgreSQL: support version encoding used in pre-10 releases Brad King (4): CMakeParseImplicitIncludeInfo: Remove all CR chars from compiler output VS: Fix support for v142 toolset minor versions in VS 16.5+ FindBLAS: Consider OpenBLAS with thread libraries only with C or CXX CMake 3.15.6 Deniz Bahadir (1): FindBoost: Prevent warning due to new meta-component "ALL" of Boost 1.73 Markus Mittendrein (1): FindGTK2: Add harfbuzz to GTK2_INCLUDE_DIRS From osmanzakir90 at hotmail.com Tue Dec 17 10:39:16 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Tue, 17 Dec 2019 15:39:16 +0000 Subject: [CMake] CMake's FindBoost Module Can't Detect Boost Version Message-ID: I built Boost 1.72.0 while passing the "--layout=versioned" flag to b2, but when I tried to rebuild Jinja2Cpp with the newer version of Boost using CMake, it failed to generate project files and said it couldn't filesystem and system and also couldn't detect version information. Could someone please help me out with this? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Tue Dec 17 11:35:49 2019 From: mateusz at loskot.net (Mateusz Loskot) Date: Tue, 17 Dec 2019 17:35:49 +0100 Subject: [CMake] CMake's FindBoost Module Can't Detect Boost Version In-Reply-To: References: Message-ID: On Tue, 17 Dec 2019 at 16:39, Osman Zakir wrote: > > I built Boost 1.72.0 while passing the "--layout=versioned" flag to b2, but when I tried to rebuild Jinja2Cpp with the newer version of Boost using CMake, it failed to generate project files and said it couldn't filesystem and system and also couldn't detect version information. Could someone please help me out with this? I recall you have been asking similar questions in the past about Jinja2Cpp. You have received number of useful suggestions [1], e.g. to use -DBoost_DEBUG=ON, and investigate detailed diagnostics, to try -DBoost_COMPILER=... and -DBoost_ARCHITECTURE hints, etc. Please, apply this knowledge. Finally, your questions are poorly formulated e.g. my crystal sphere has broken and I can't figure out what compiler, toolset, cmake version, etc. you are on. Next time, try to help people help you [2] [1] https://cmake.org/pipermail/cmake/2018-October/068477.html [2] http://www.catb.org/~esr/faqs/smart-questions.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From osmanzakir90 at hotmail.com Tue Dec 17 12:43:46 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Tue, 17 Dec 2019 17:43:46 +0000 Subject: [CMake] CMake's FindBoost Module Can't Detect Boost Version In-Reply-To: References: , Message-ID: I tried passing -DBoost_COMPILER and -DBoost_DEBUG but it seems it's only looking for up to Boost 1.71.0; the test versions go up to there only. Should I edit the FindBoost.cmake file to have it look for version 1.72.0 as well? I'm using MSVC version 14.2, Visual Studio 2019. I'm using the Developer Command Prompt for VS2019. I don't know about all of the flags I need to pass, but if it can find the Boost version then it should be able to detect all of the stuff on its own, right? The first step there isn't going right. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Tue Dec 17 13:03:27 2019 From: mateusz at loskot.net (Mateusz Loskot) Date: Tue, 17 Dec 2019 19:03:27 +0100 Subject: [CMake] CMake's FindBoost Module Can't Detect Boost Version In-Reply-To: References: Message-ID: On Tue, 17 Dec 2019 at 18:43, Osman Zakir wrote: > > I tried passing -DBoost_COMPILER and -DBoost_DEBUG That is incorrect! The options must read -DBoost_DEBUG=ON and -DBoost_COMPILER=-vc141 or vc142, depending on what b2.exe generated in names for your MSVC version. > but it seems it's only looking for up to Boost 1.71.0; the test versions go up to there only. > Should I edit the FindBoost.cmake file to have it look for version 1.72.0 as well? If you have read/searched the FindBoost docs page https://cmake.org/cmake/help/latest/module/FindBoost.html?highlight=version you would have learned that you can specify -DBoost_ADDITIONAL_VERSIONS=1.72 > I don't know about all of the flags I need to pass, but if it can find the Boost version then it should be able to detect all of the stuff on its own, right? It should, but it still may need hints like Boost_COMPILER, or Boost_ARCHITECTURE. FindBoost is a Find-module. A Find-module is a ***guesser***. A guesser has right to fail to guess...no hard promises. https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html "Unlike a package configuration file, it is not shipped with upstream, but is used by downstream to find the files by guessing locations of files with platform-specific hints." Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From osmanzakir90 at hotmail.com Tue Dec 17 17:23:20 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Tue, 17 Dec 2019 22:23:20 +0000 Subject: [CMake] CMake's FindBoost Module Can't Detect Boost Version In-Reply-To: References: , Message-ID: Yeah, forgot. I did specify the values for the flags on the actual thing. -DBoost_COMPILER=-vc142, -DBoost_ARCHITECTURE=-x64 and -DBoost_DEBUG=ON. I'll try specifying the version number like what you said. Thanks for that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbahadir at benocs.com Wed Dec 18 08:50:22 2019 From: dbahadir at benocs.com (Deniz Bahadir) Date: Wed, 18 Dec 2019 14:50:22 +0100 Subject: [CMake] CMake's FindBoost Module Can't Detect Boost Version In-Reply-To: References: Message-ID: <764b8cd9-d0e2-40d1-1015-18233e8596b2@benocs.com> Am 17.12.19 um 17:35 schrieb Mateusz Loskot: > On Tue, 17 Dec 2019 at 16:39, Osman Zakir wrote: >> >> I built Boost 1.72.0 while passing the "--layout=versioned" flag to b2, but when I tried to rebuild Jinja2Cpp with the newer version of Boost using CMake, it failed to generate project files and said it couldn't filesystem and system and also couldn't detect version information. Could someone please help me out with this? > > I recall you have been asking similar questions in the past about Jinja2Cpp. > > You have received number of useful suggestions [1], e.g. to use > -DBoost_DEBUG=ON, > and investigate detailed diagnostics, to try -DBoost_COMPILER=... > and -DBoost_ARCHITECTURE hints, etc. > Please, apply this knowledge. > > Finally, your questions are poorly formulated e.g. my crystal sphere has broken > and I can't figure out what compiler, toolset, cmake version, etc. you are on. > Next time, try to help people help you [2] > > [1] https://cmake.org/pipermail/cmake/2018-October/068477.html > [2] http://www.catb.org/~esr/faqs/smart-questions.html > > Best regards, > Osman, as you are obviously trying to to find a pretty recent Boost version (1.72.0) that you even built yourself, you could probably try to skip the Module-mode of the `find_package(Boost ...)` call and instead try to use the Config-mode directly, like this: ``` find_package(Boost 1.72.0 EXACT CONFIG ...) ``` Thereby, you are skipping CMake's FindBoost module entirely and instead rely on the BoostConfig.cmake file provided by Boost itself. (Then you can even skip defining the `Boost_ADDITIONAL_VERSIONS` variable.) However, if you did not install your Boost version in one of the default-locations you probably need to provide some HINTs or PATHs to `find_package`. See [3] for further information. Nevertheless, if you have a pretty recent version of CMake with a pretty recent version of its FindBoost module, then even in Module mode the FindBoost module will first try to find BoostConfig.cmake. [3] https://cmake.org/cmake/help/latest/command/find_package.html#full-signature-and-config-mode Best regards, Deniz PS: This mailing-list will probably be discontinued within the next few weeks. For future questions you should probably switch to https://discourse.cmake.org, as that is the successor of the CMake mailing-lists. From cornelis at bockemuehl.ch Thu Dec 19 04:52:30 2019 From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=) Date: Thu, 19 Dec 2019 10:52:30 +0100 Subject: [CMake] Suppress a specific path in the RPATH of an executable explicitly Message-ID: <56eb-5dfb4880-5f-2b941880@121693222> In a project setup I am copying a number of shared library files into the executable directory (basically with a mechanism involving configure_file - because the "install" logic was simply too complicated for the project and for my limited brain capacity!). On a Windows system this works nicely, but on a Linux system there is always some logic that puts the original shared library location into the executable's RUNPATH, with the effect that they are not found in the place where they are supposed to be found. I tried to avoid this by using set_target_properties( ??? ??? PROPERTIES ??????? CMAKE_SKIP_RPATH TRUE)However, any effect was not visible: the "old" path is still included in RUNPATH. Maybe I overlooked one more imported target, overriding the effect of above, or it does not work on imported targets at all. Anyway, it would be much easier if I could simply drop one specific path explicitly with some setting! Dropping all is again too much - because I need other entries for other libraries. Is there such an option available? Maybe a workaround would be to explicitly prepend "$ORIGIN" to the RUNPATH in the executable: In this way the shared libs would be found in the executable directory first and any other "wrong" paths would not hurt. Many thanks and regards, Cornelis Bockem?hl -------------- next part -------------- An HTML attachment was scrubbed... URL: From doenges at mvtec.com Thu Dec 19 05:52:55 2019 From: doenges at mvtec.com (=?UTF-8?Q?Eric_D=c3=b6nges?=) Date: Thu, 19 Dec 2019 11:52:55 +0100 Subject: [CMake] Suppress a specific path in the RPATH of an executable explicitly In-Reply-To: <56eb-5dfb4880-5f-2b941880@121693222> References: <56eb-5dfb4880-5f-2b941880@121693222> Message-ID: <625f1d56-18d9-83da-f25c-e5cd1bf16523@mvtec.com> On 19.12.19 10:52, Cornelis Bockem?hl wrote: > In a project setup I am copying a number of shared library files into > the executable directory (basically with a mechanism involving > configure_file - because the "install" logic was simply too complicated > for the project and for my limited brain capacity!). > > On a Windows system this works nicely, but on a Linux system there is > always some logic that puts the original shared library location into > the executable's RUNPATH, with the effect that they are not found in the > place where they are supposed to be found. > > I tried to avoid this by using > > set_target_properties( > ??? > ??? PROPERTIES > ??????? CMAKE_SKIP_RPATH TRUE) This cannot work because CMAKE_SKIP_RPATH is a variable, not a property. Variables are set with the set() command (or from the command line with the -D option), and often serve as the default values for a specific property if that property isn't explicitly set. Properties are set with set_property() or set_target_properties() and apply only to the specific target they are set for. In general, anything with a 'CMAKE_' prefix is a variable, not a property. Note that CMake distinguishes between "build time" and "install time" rpath, allowing you to have different rpaths for the binaries in your build and install directories. So if you do not want any rpath information added to your binaries, you would set(CMAKE_SKIP_RPATH TRUE) set(CMAKE_SKIP_INSTALL_RPATH TRUE) before defining any targets. If you want to control the rpath for individual binaries, you would set the appropriate properties for the binary target(s) whose rpath you want to set. Check the CMake documentation for properties containing 'RPATH' to see which properties are available - there is quite a number of them. As far as I know, these properties are not transitive, so you cannot set the rpath for a shared library and expect targets linked against that library to receive this rpath. It sounds to me that what you probably want to do is set the RPATH of your executables to look in $ORIGIN and nowhere else. One way to do this would be to set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) set(CMAKE_INSTALL_RPATH "$ORIGIN") before defining your targets. If you want control over individual targets, you would set the BUILD_WITH_INSTALL_RPATH and INSTALL_RPATH properties on the individual targets. For more details, see https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling. From robert.maynard at kitware.com Thu Dec 19 11:18:34 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 19 Dec 2019 11:18:34 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.16.2 available for download Message-ID: We are pleased to announce that CMake 3.16.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.16.2 since 3.16.1: Brad King (6): VS: Fix support for v142 toolset minor versions in VS 16.5+ FindBLAS: Consider OpenBLAS with thread libraries only with C or CXX FindBoost: Add support for Boost 1.72 Autogen: Revert processing of .hh files for compatibility FindLAPACK: Fix support for LAPACK symbols inside BLAS libraries CMake 3.16.2 Cristian Adam (1): PCH: Append pch header file to list of forced include files Michael Dickens (1): Tests: Fix testCTestResourceSpec struct initialization for some compilers From sancelot at numalliance.com Thu Dec 19 13:26:41 2019 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Thu, 19 Dec 2019 19:26:41 +0100 Subject: [CMake] msys2-mingw64 cmake gives undefined behaviour, can not find include header Message-ID: Hi, Migrating a code to msys2 compilation (cmake inside msys ), it does not find an include file for unknwon reason. the file is located in a project defined as follow: cmake_minimum_required(VERSION 3.10) project(include_commun) add_library(include_commun INTERFACE) target_include_directories(include_commun INTERFACE?? .) and the project causing error : cmake_minimum_required(VERSION 3.10) project(import_export_unix) add_library(import_export_unix STATIC import_export_unix.h import_export_unix.cpp) set_target_properties(import_export_unix PROPERTIES POSITION_INDEPENDENT_CODE TRUE) target_include_directories(import_export_unix PUBLIC .) target_link_libraries(import_export_unix PRIVATE include_machine include_commun) error displayed : [? 3%] Building CXX object IMPORT_EXPORT_UNIX/CMakeFiles/import_export_unix.dir/import_export_unix.cpp.obj cd /e/WORKSPACE/BASE_SILFAX_SAFETY/build/IMPORT_EXPORT_UNIX && /mingw64/bin/c++.exe @CMakeFiles/import_export_unix.dir/includes_CXX.rsp? -o CMakeFiles/import_export_unix.dir/import_export_unix.cpp.obj -c /e/WORKSPACE/BASE_SILFAX_SAFETY/IMPORT_EXPORT_UNIX/import_export_unix.cpp E:/WORKSPACE/BASE_SILFAX_SAFETY/IMPORT_EXPORT_UNIX/import_export_unix.cpp:19:10: fatal error: defprog.h: No such file or directory CMakeFiles/import_export_unix.dir/includes_CXX.rsp content : -I/e/WORKSPACE/BASE_SILFAX_SAFETY/IMPORT_EXPORT_UNIX/. -I/e/WORKSPACE/BASE_SILFAX_SAFETY/INCLUDE_MACHINE/. -I/e/WORKSPACE/BASE_SILFAX_SAFETY/INCLUDE_COMMUN/. Regards, Steph -------------- next part -------------- An HTML attachment was scrubbed... URL: From angroyer at lincolnelectric.com Fri Dec 20 10:49:23 2019 From: angroyer at lincolnelectric.com (angroyer) Date: Fri, 20 Dec 2019 08:49:23 -0700 (MST) Subject: [CMake] Qt translation handling In-Reply-To: References: Message-ID: <1576856963536-0.post@n2.nabble.com> Bonjour Francis, thank you for sharing this snippet. I have read thoroughly your example and tried it but it seems to me that this snippet is similar to the qt5_create_translation() function. First of all, with cmake >= 3.0.0 and AUTORCC set to ON, adding ${CMAKE_CURRENT_BINARY_DIR}/translations.qrc in add_executable() make the executable depends on the translations.qrc and make also translations.qrc depends on the files listed in the translations.qrc. So everytime a .qm listed in translations.qrc changes, the qrc_translations.cpp is created and compiled. So, it is not necessary to add ${QM_FILES} in the add_executable() statement. So, with your piece of code: * ${CMAKE_CURRENT_BINARY_DIR}/translations.qrc in add_executable make App depend on the qrc_translations.qrc and qrc_translations.qrc depend on files listed in qrc_translations.qrc * each .qm file is dependent on a .ts file: statement qt5_add_translation() * each .ts file is dependent on ${TS_SOURCES}: statement add_custom_command() So everytime a file listed in ${TS_SOURCES} changes, the .ts is rebuilt, the .qm is rebuilt and the qrc_translations.cpp is compiled. You could have obtained the same thing with: set(TS_FILES ${CMAKE_CURRENT_SOURCE_DIR}/translations/app_fr.ts ) file(GLOB_RECURSE TS_SOURCES "*.cpp" "*.h" "*.ui") qt5_create_translation(QM_FILES ${TS_FILES} ${TS_SOURCES}) configure_file(translations.qrc ${CMAKE_CURRENT_BINARY_DIR} COPYONLY) add_executable(App ${CMAKE_CURRENT_BINARY_DIR}/translations.qrc ) and translations.qrc containing: gui_fr.qm I have tested with cmake 3.16.1. It is worth mentioning that the Qt documentation: https://doc.qt.io/qt-5/qtlinguist-cmake-qt5-create-translation.html indicates: qt5_create_translation(QM_FILES ${CMAKE_SOURCE_DIR} helloworld_en.ts helloworld_de.ts) without passing the list of source/headers files. So the .ts files are reconstructed when the date of the source folder changes but not for the date of the subdirectories. The date of the source folder changes when some files are created/removed/modified in the directory but not for the files in subdirectories. This could leads to errors since the .ts files would not be rebuilt when a file in a subdirectory change. So changing from branch to branch might change the date of the source folder and regenerates the .ts files. What do you think ? In case you want to keep the .qm files in your source folder, you could indicate to the cmake rule where to generate the .qm file with the OUTPUT_LOCATION: set_source_files_properties(${TS_FILES} PROPERTIES OUTPUT_LOCATION ${CMAKE_SOURCE_DIR}/translations) See https://doc.qt.io/qt-5/qtlinguist-cmake-qt5-add-translation.html It works also for qt5_create_translation() that calls in turn the qt5_add_translation(). And so you do not need to copy the translations.qrc to the build folder. The code becomes: set(TS_FILES ${CMAKE_CURRENT_SOURCE_DIR}/translations/app_fr.ts ) set_source_files_properties(${TS_FILES} PROPERTIES OUTPUT_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/translations) file(GLOB_RECURSE TS_SOURCES "*.cpp" "*.h" "*.ui") qt5_create_translation(QM_FILES ${TS_FILES} ${TS_SOURCES}) add_executable(App translations/translations.qrc ) and translations/translations.qrc containing: gui_fr.qm Cordialement, Anthony -- Sent from: http://cmake.3232098.n2.nabble.com/ From angroyer at lincolnelectric.com Mon Dec 23 09:03:58 2019 From: angroyer at lincolnelectric.com (angroyer) Date: Mon, 23 Dec 2019 07:03:58 -0700 (MST) Subject: [CMake] Qt translation handling In-Reply-To: <1576856963536-0.post@n2.nabble.com> References: <1576856963536-0.post@n2.nabble.com> Message-ID: <1577109838102-0.post@n2.nabble.com> Another thing: in case you don't want to re-generate the .ts files every time, you could comment out: file(GLOB_RECURSE TS_SOURCES "*.cpp" "*.h" "*.ui") qt5_create_translation(QM_FILES ${TS_FILES} ${TS_SOURCES}) and use instead the following line with the .ts files already committed in your project: qt5_add_translation(QM_FILES ${TS_FILES}) Cordialement Anthony -- Sent from: http://cmake.3232098.n2.nabble.com/ From craig.scott at crascit.com Sat Dec 28 07:26:47 2019 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 28 Dec 2019 23:26:47 +1100 Subject: [CMake] Providing multiple different MAJOR API versions with write_basic_package_version_file In-Reply-To: <4294aea45b9723333bfdcdd3cc5258cb0c119db4.camel@codeminded.be> References: <4294aea45b9723333bfdcdd3cc5258cb0c119db4.camel@codeminded.be> Message-ID: On Mon, Nov 4, 2019 at 10:54 PM Philip Van Hoof wrote: > Hello, > > After Craig's very interesting presentation at CppCon 2019* I learned a > bunch of new things which I of course immediately wanted to try out**. > > I read about the write_basic_package_version_file which is in > CMakePackageConfigHelpers. Craig also mentioned in the presentation > that you can have a so called API-version in the target's name. And > that for example Qt does this (Qt5Core, which has the MAJOR number 5 in > its target name). > > For my target name I prefer to have the API version after a dash, like > how GLib and DBus packages do it: libglib-2.0.so.0.6200.1 on current > Ubuntu, for example in /usr/lib/x86_64-linux-gnu. > Understand that from CMake's point of view, the library name is then glib-2.0 and the fact that it contains numbers that look like a version of some kind is completely irrelevant (to CMake). You could just as well have called it glib-specialsauce. Putting an API version into the library name is *changing* the library name to something else. This is particularly inconvenient for projects using find_package() to find your library, since they have to specify the exact API version now because you've included it in the library name. glib-2.0 is a completely different library to glib-2.1, for example. It might be more precise, but it is less convenient to consume. You could potentially remove that inconvenience by naming the config package file glibConfig.cmake instead of glib-2.0Config.cmake, then place it under an API-versioned directory that find_package() would search in, but that would seem to remove the very advantage you are trying to gain by putting the API version in the library name. The consuming project would effectively be able to ignore the API version if you did this. > > I wonder what that means for the property of > write_basic_package_version_file. In the autotools and meson world, the > usage of pkg-config files seems to indicate that the same filename > naming scheme applies to the .pc file: > > /usr/lib/x86_64-linux-gnu/pkgconfig/glib-2.0.pc > > This allows me to distinguish between older MAJOR API versions of GLib > and newer MAJOR API versions of it, using FindPkgConfig*** > > Supposedly something similar is possible with find_package's .cmake > files as installed by write_basic_package_version_file? > As above, you are creating an entirely different library by putting the API version in its base name. So your call to find_package() would be looking for that API-specific name and your package version file would have to match that expected name too. > > How do I provide a PackageNameConfigVersion.cmake for major version 1.0 > and 2.0 (the equivalent of PackageName-1.0.pc and PackageName-2.0.pc in > the pkgconfig directory)? > Since from CMake's perspective they are two completely different libraries, you'd end up with PackageName-1.0ConfigVersion.cmake and PackageName-2.0ConfigVersion.cmake as the file names. > > Kind regards, > > Philip > > * https://www.youtube.com/watch?v=m0DwB4OvDXk > ** > https://github.com/pvanhoof/dir-examples/commit/523cab5edaff99acba037218d5b95227cb2487a9 > *** https://cmake.org/cmake/help/v3.15/module/FindPkgConfig.html I've debated whether to express my own opinion on this, but in this case I'll risk it. I personally find that putting an API version in the name of the library itself to be an annoyance. I'm typically interested in the ABI versioning, and I take on the responsibility of understanding how that maps to the API. If semantic versioning is being followed for the ABI versioning, then this mapping is typically trivial. To me, any gains from making the API version explicit in the library name are less significant than the negative impact on the ease of consuming that library and the added "scare factor" of an overly complicated versioning system. Versioning is already complex enough for most users, if we can avoid making it more so, then users will likely appreciate that. It may be instructive to note that there were changes in CMake 3.14 to support Qt being found without the API version being specified as part of the package name (i.e. as find_package(Qt)). See policy CMP0084 for some brief background. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide Consulting services (CMake, C++, build/release processes): https://crascit.com/services -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Dec 28 20:15:10 2019 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 29 Dec 2019 12:15:10 +1100 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> Message-ID: This one has sat in my inbox for a long time - sorry I'm only getting to it now! On Wed, Sep 18, 2019 at 9:21 AM Alan W. Irwin wrote: > Hi Craig: > > It appears you pretty much made the definitive statement about > target_link_libraries (TLL) options at > . However, > I have some further questions about this key section of your > statement: > > "[...] when A links in B as PRIVATE, the include directories of B > never propagate to something linking to A, but if A is a static > library, then the *linking* of B behaves as though the relationship > was PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries > only applies to the *linking*, not to the other dependencies (compiler > options/flags and include search paths). The upshot of all this is > that if you select PRIVATE, PUBLIC or INTERFACE based on the > explanations in the dot points above, then CMake will ensure > dependencies propagate through to where they are required, regardless > of whether libraries are static or shared. This does, of course, rely > on you the developer not missing any dependencies or specifying the > wrong PRIVATE/PUBLIC/INTERFACE relationship." > > The issues I am concerned with are the following: > > * The target_include_directories, target_compile_definitions, and > target_compile_options (TID, TCD, and TCO) commands all have > options. I am pretty sure those options > must take precedence over the TLL options, > but can you confirm that? > No that's not a correct interpretation. For target_include_directories(), target_compile_definitions() and target_compile_options(), a PRIVATE item only applies to that target, meaning it only affects how that target is built. An INTERFACE item would affect how some other target that links to that target is built. This is true even if that other target does a PRIVATE link to this target. The PRIVATE/INTERFACE/PUBLIC specification in target_link_libraries() is somewhat like a next layer out. Let me try to explain via an example. Let's say we have three libraries: inner, middle and outer, where outer links to middle and middle links to inner. The outer library doesn't reference anything from the inner library directly. We would express it something like this: target_compile_definitions(inner PUBLIC SomeSetting=true) # Used in discussion below target_link_libraries(middle XXXX inner) target_link_libraries(outer PRIVATE middle) The inner library defines the SomeSetting=true definition as PUBLIC, so both inner and middle will have this definition applied to them. - If XXXX is PRIVATE, the middle library links to inner as PRIVATE, so the SomeSetting=true definition remains hidden from the outer library. - If XXXX is PUBLIC, the middle library links to inner as PUBLIC, so the SomeSetting=true definition is applied transitively to anything that links to middle. That means that outer will now have the SomeSetting=true definition applied to it as well. I recommend you play around with variations of the above example and see the command lines that are generated. It is probably the most effective way to solidify one's understanding and answer questions about how the relationships work. For your convenience, here's a complete working example that you can start with: cmake_minimum_required(VERSION 3.16) project(pubpriv) add_library(inner inner.cpp) add_library(middle middle.cpp) add_library(outer outer.cpp) target_compile_definitions(inner PUBLIC SomeSetting=true) target_compile_definitions(middle PRIVATE OtherSetting=true) target_link_libraries(middle PUBLIC inner) target_link_libraries(outer PRIVATE middle) > > * It appears to me that if a CMake-based build system is configured > properly there is very little need for the PUBLIC option for TLL > because PRIVATE works well for shared libraries and the > PRIVATE-becomes-PUBLIC behaviour for static libraries you mentioned > above. Can you confirm this statement is generally true both for > Unix and Windows? > Continuing with the example I used above, if the public headers of the middle library refer to anything from the inner library, then target_link_libraries() should specify PUBLIC, regardless of whether middle or inner are static or shared libraries. Simon's reply already highlighted cases involving inlined functions where this is important. The platform is not relevant here, the same behavior applies to all platforms. > > I am concerned with the above issues because the PLplot build system > currently does the following: > > * For shared libraries uses the PRIVATE TLL option for the Unix case > and PUBLIC TLL option for the Windows case. > I don't understand the rationale for this. Perhaps it is related to Visual Studio making symbols hidden by default, but Clang and GCC making symbols visible by default (see my CppCon 2019 talk for a discussion of this and the CMake features related to it). > > * For static libraries always uses the PUBLIC TLL option. > The right choice of PUBLIC, PRIVATE or INTERFACE is independent of whether the libraries are static or shared. > > These decisions were based on my own understanding of transitive > linking needs for static Unix libraries and shared and static Windows > libraries many years ago, but now it appears that understanding is out > of date or else was wrong in the first place. > > For example, in the static Linux case there is a nasty leakage of > compile and link flags between static libraries that I have just > tripped over when dealing with the D ldc2 compiler which cannot > understand those flags which are generated for the gcc compiler for a > C library which our D library depends on. So to stop that leakage, > and in light of what you said three years ago, it appears to be a > no-brainer to use PRIVATE TLL for the PLplot static libraries at least > in the Unix case. So assuming that for the PLplot build system I > follow up and prove that PRIVATE TLL works for both the shared and > static library cases on Unix, would you also recommend PLplot move to > PRIVATE TLL for both the shared and static library cases on Windows? > For all the target_...() commands, my recommendation is to make things PRIVATE by default and only use PUBLIC or INTERFACE if the relationship genuinely requires the thing in question to be applied to whatever links to that target. The platform is not a factor unless the API is different on different platforms. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide Consulting services (CMake, C++, build/release processes): https://crascit.com/services -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.W.Irwin1234 at gmail.com Sun Dec 29 15:55:19 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Sun, 29 Dec 2019 12:55:19 -0800 (PST) Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> Message-ID: On 2019-12-29 12:15+1100 Craig Scott wrote: > This one has sat in my inbox for a long time - sorry I'm only getting to it > now! No problem, and big thanks for replying late rather than taking the easier course of replying never. I haven't yet absorbed all of what you said, but I am sure your answers will be a big help to my project to modernize the CMake-base build system for PLplot which was originally "designed" in 2006 by a team of CMake newbies (including me). Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________