From robert.maynard at kitware.com Wed Oct 2 13:00:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 2 Oct 2019 13:00:00 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.14.7 available for download Message-ID: We are pleased to announce that CMake 3.14.7 is now available for download. This release fixes a regression in EXCLUDE_FROM_ALL. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.14.7 since 3.14.6: Brad King (6): Tests: Teach RunCMake to support a custom working directory Tests: Revise RunCMake.add_subdirectory ExcludeFromAll to avoid globbing Tests: Clarify target names in RunCMake.add_subdirectory ExcludeFromAll Restore "all" target in subdirectories marked EXCLUDE_FROM_ALL Help: Add release note for EXCLUDE_FROM_ALL fix in 3.14.7 CMake 3.14.7 From robert.maynard at kitware.com Wed Oct 2 13:10:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 2 Oct 2019 13:10:00 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.15.4 available for download Message-ID: We are pleased to announce that CMake 3.15.4 is now available for download. This release fixes a regression in EXCLUDE_FROM_ALL. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.15.4 since 3.15.3: Brad King (10): VS: Tell VS 16.4 not to verify SYMBOLIC custom command outputs Tests: Teach RunCMake to support a custom working directory Tests: Revise RunCMake.add_subdirectory ExcludeFromAll to avoid globbing Tests: Clarify target names in RunCMake.add_subdirectory ExcludeFromAll Makefiles: Revert "Make build root targets ... recursive" Restore "all" target in subdirectories marked EXCLUDE_FROM_ALL Help: Add release note for EXCLUDE_FROM_ALL fix in 3.14.7 Help: Add release note for EXCLUDE_FROM_ALL fix in 3.15.4 Help: Mention 3.14.7 EXCLUDE_FROM_ALL fix in 3.15.4 release note CMake 3.15.4 LE GARREC Vincent (1): Help: Document VS 2019 toolset in MSVC_TOOLSET_VERSION From dustyn at blasig.us Thu Oct 3 12:26:45 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Thu, 3 Oct 2019 11:26:45 -0500 Subject: [CMake] Use interface libraries for providing compile options and definitions Message-ID: Hi All, I have been cleaning up our legacy CMake to use newer features (available in 3.12+) including trying to use target_...() functions nearly exclusively. As part of this, I was toying with cleaning up our use cases for adding compiler flags and similar definitions using real targets and target_link_libraries. For instance, as a simple example, let's say I wanted to add/provide a definition MY_FLAG, I could do something like... ``` add_library(my_flag INTERFACE) target_compile_definitions(my_flag INTERFACE MY_FLAG=1) add_library(other_library SHARED ...) target_link_libraries(other_library ... *PRIVATE *my_flag) export/install rules ``` I want this library to be private to my component, and it's only used under the PRIVATE banner. However, the issue I'm running into is with the install/export rules. I get an error similar to ... ``` CMake Error: install(EXPORT "MY_PROJECT" ...) includes target "other_library" which requires target "my_flag" that is not in the export set. ``` If my_flag is defined in my component, I can add it to the export set perhaps to workaround the issue, but in many cases, it would be coming from a helper script in another sub-project I'm fetching using FetchContent and don't want to expose the functionality via my export scripts. (1) Is it recommended to use interface libraries to clean up compile defintions, etc. (2) Should it be possible to link privately such libraries and not have the export functionality complain? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at seefeld.name Thu Oct 3 16:15:55 2019 From: stefan at seefeld.name (stefan) Date: Thu, 3 Oct 2019 16:15:55 -0400 Subject: [CMake] HOWTO declare component inter-dependencies in multi-component packages Message-ID: I'm trying to generate (debian) packages for a project of mine using cmake. I need to generate multiple components ("runtime", "development", etc.). What is the expected way to have the "development" package depend on the "runtime" package ? I'v been trying to play with the CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS setting, but so far wasn't able to have my packages contain the expected dependencies in their metadata. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 1478 bytes Desc: not available URL: From kyle.edwards at kitware.com Thu Oct 3 16:23:47 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 03 Oct 2019 16:23:47 -0400 Subject: [CMake] HOWTO declare component inter-dependencies in multi-component packages In-Reply-To: References: Message-ID: <1570134227.3676.9.camel@kitware.com> On Thu, 2019-10-03 at 16:15 -0400, stefan wrote: > I'm trying to generate (debian) packages for a project of mine using > cmake. I need to generate multiple components ("runtime", > "development", etc.). What is the expected way to have the > "development" package depend on the "runtime" package ? > I'v been trying to play with the > CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS setting, but so far wasn't able > to have my packages contain the expected dependencies in their > metadata. > Thanks, Please take a look at cpack_add_component(): https://cmake.org/cmake/help/latest/module/CPackComponent.html Kyle From stefan at seefeld.name Thu Oct 3 16:30:26 2019 From: stefan at seefeld.name (stefan) Date: Thu, 3 Oct 2019 16:30:26 -0400 Subject: [CMake] HOWTO declare component inter-dependencies in multi-component packages In-Reply-To: <1570134227.3676.9.camel@kitware.com> References: <1570134227.3676.9.camel@kitware.com> Message-ID: <03301e84-711f-0d07-410a-d8d955e96ae7@seefeld.name> Hi Kyle, thanks for the quick followup. On 2019-10-03 4:23 p.m., Kyle Edwards wrote: > Please take a look at cpack_add_component(): > https://cmake.org/cmake/help/latest/module/CPackComponent.html I'm not sure what specifically I should be looking for. In general my setup is working fine, i.e. my build generates multiple packages as expected. They even contain dependencies to external packages, as I have set as per the available variables. What I haven't been able to express is the component inter-dependency. That is, I haven't found a way to make my "development" package depend on the "runtime" package (generated from the same build process). Sorry for being obtuse. Stefan -- ...ich hab' noch einen Koffer in Berlin... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 1478 bytes Desc: not available URL: From kyle.edwards at kitware.com Thu Oct 3 16:37:10 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 03 Oct 2019 16:37:10 -0400 Subject: [CMake] HOWTO declare component inter-dependencies in multi-component packages In-Reply-To: <03301e84-711f-0d07-410a-d8d955e96ae7@seefeld.name> References: <1570134227.3676.9.camel@kitware.com> <03301e84-711f-0d07-410a-d8d955e96ae7@seefeld.name> Message-ID: <1570135030.3676.10.camel@kitware.com> On Thu, 2019-10-03 at 16:30 -0400, stefan wrote: > Hi Kyle, > thanks for the quick followup. > On 2019-10-03 4:23 p.m., Kyle Edwards wrote: > > Please take a look at cpack_add_component(): > > https://cmake.org/cmake/help/latest/module/CPackComponent.html > I'm not sure what specifically I should be looking for. > In general my setup is working fine, i.e. my build generates multiple > packages as expected. They even contain dependencies to external > packages, as I have set as per the available variables. What I > haven't been able to express is the component inter-dependency. That > is, I haven't found a way to make my "development" package depend on > the "runtime" package (generated from the same build process). > Sorry for being obtuse. In particular, please look at the DEPENDS argument of cpack_add_component(): "DEPENDS lists the components on which this component depends. If this component is selected, then each of the components listed must also be selected. The dependency information is encoded within the installer itself, so that users cannot install inconsistent sets of components." Kyle From stefan at seefeld.name Thu Oct 3 16:42:50 2019 From: stefan at seefeld.name (stefan) Date: Thu, 3 Oct 2019 16:42:50 -0400 Subject: [CMake] HOWTO declare component inter-dependencies in multi-component packages In-Reply-To: <1570135030.3676.10.camel@kitware.com> References: <1570134227.3676.9.camel@kitware.com> <03301e84-711f-0d07-410a-d8d955e96ae7@seefeld.name> <1570135030.3676.10.camel@kitware.com> Message-ID: On 2019-10-03 4:37 p.m., Kyle Edwards wrote: > On Thu, 2019-10-03 at 16:30 -0400, stefan wrote: >> Hi Kyle, >> thanks for the quick followup. >> On 2019-10-03 4:23 p.m., Kyle Edwards wrote: >>> Please take a look at cpack_add_component(): >>> https://cmake.org/cmake/help/latest/module/CPackComponent.html >> I'm not sure what specifically I should be looking for. >> In general my setup is working fine, i.e. my build generates multiple >> packages as expected. They even contain dependencies to external >> packages, as I have set as per the available variables. What I >> haven't been able to express is the component inter-dependency. That >> is, I haven't found a way to make my "development" package depend on >> the "runtime" package (generated from the same build process). >> Sorry for being obtuse. > In particular, please look at the DEPENDS argument of > cpack_add_component(): > > "DEPENDS lists the components on which this component depends. If this > component is selected, then each of the components listed must also be > selected. The dependency information is encoded within the installer > itself, so that users cannot install inconsistent sets of components." My project is already using this style: ? set(CPACK_COMPONENTS_ALL runtime development mstool) i.e. all components are already defined. All that's missing is the declaration of their (inter-)dependencies. Are you suggesting I should *not* use CPACK_COMPONENTS_ALL, but instead call `cpack_add_component()` instead ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 1478 bytes Desc: not available URL: From kyle.edwards at kitware.com Thu Oct 3 16:59:46 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 03 Oct 2019 16:59:46 -0400 Subject: [CMake] HOWTO declare component inter-dependencies in multi-component packages In-Reply-To: References: <1570134227.3676.9.camel@kitware.com> <03301e84-711f-0d07-410a-d8d955e96ae7@seefeld.name> <1570135030.3676.10.camel@kitware.com> Message-ID: <1570136386.3676.11.camel@kitware.com> On Thu, 2019-10-03 at 16:42 -0400, stefan wrote: > My project is already using this style: > ? set(CPACK_COMPONENTS_ALL runtime development mstool) > > i.e. all components are already defined. All that's missing is the > declaration of their (inter-)dependencies. > Are you suggesting I should *not* use CPACK_COMPONENTS_ALL, but > instead call `cpack_add_component()` instead ? > Thanks, That's how I prefer to do it. Alternatively, you could set CPACK_COMPONENT__DEPENDS directly (that's all that cpack_add_component() is doing.) Kyle From stefan at seefeld.name Thu Oct 3 17:08:09 2019 From: stefan at seefeld.name (stefan) Date: Thu, 3 Oct 2019 17:08:09 -0400 Subject: [CMake] HOWTO declare component inter-dependencies in multi-component packages In-Reply-To: <1570136386.3676.11.camel@kitware.com> References: <1570134227.3676.9.camel@kitware.com> <03301e84-711f-0d07-410a-d8d955e96ae7@seefeld.name> <1570135030.3676.10.camel@kitware.com> <1570136386.3676.11.camel@kitware.com> Message-ID: On 2019-10-03 4:59 p.m., Kyle Edwards wrote: > On Thu, 2019-10-03 at 16:42 -0400, stefan wrote: >> My project is already using this style: >> ? set(CPACK_COMPONENTS_ALL runtime development mstool) >> >> i.e. all components are already defined. All that's missing is the >> declaration of their (inter-)dependencies. >> Are you suggesting I should *not* use CPACK_COMPONENTS_ALL, but >> instead call `cpack_add_component()` instead ? >> Thanks, > That's how I prefer to do it. Alternatively, you could set > CPACK_COMPONENT__DEPENDS directly (that's all that > cpack_add_component() is doing.) Yes, that is exactly what I'm trying to do, but it doesn't seem to have any effect. That is, `dpkg --info ...` doesn't list the additional dependency, and correspondingly, running `apt-get install ...` on the component package file will install the package without first installing the prerequisite component. Consider this declaration: ? set(CPACK_COMPONENTS_ALL runtime development mstool) If I now write ? set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS runtime) I will see no effect. That is, the "development" package still does not depend on the "runtime" package. So I try this: ? set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS RUNTIME) in case capitalization is required. Now the "runtime" component seems to get packaged twice (as per the cmake logs), but still no correct dependencies. Is it time for a bug report ? Stefan -- ...ich hab' noch einen Koffer in Berlin... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 1478 bytes Desc: not available URL: From kyle.edwards at kitware.com Thu Oct 3 17:24:36 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 03 Oct 2019 17:24:36 -0400 Subject: [CMake] HOWTO declare component inter-dependencies in multi-component packages In-Reply-To: References: <1570134227.3676.9.camel@kitware.com> <03301e84-711f-0d07-410a-d8d955e96ae7@seefeld.name> <1570135030.3676.10.camel@kitware.com> <1570136386.3676.11.camel@kitware.com> Message-ID: <1570137876.3676.12.camel@kitware.com> On Thu, 2019-10-03 at 17:08 -0400, stefan wrote: > Yes, that is exactly what I'm trying to do, but it doesn't seem to > have any effect. That is, `dpkg --info ...` doesn't list the > additional dependency, and correspondingly, running `apt-get install > ...` on the component package file will install the package without > first installing the prerequisite component. > Consider this declaration: > ? set(CPACK_COMPONENTS_ALL runtime development mstool) > If I now write > ? set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS runtime) > I will see no effect. That is, the "development" package still does > not depend on the "runtime" package. > So I try this: > ? set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS RUNTIME) > in case capitalization is required. Now the "runtime" component seems > to get packaged twice (as per the cmake logs), but still no correct > dependencies. > Is it time for a bug report ? Please send us a minimal CMakeLists.txt that reproduces the issue. Kyle From craig.scott at crascit.com Thu Oct 3 18:29:49 2019 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 4 Oct 2019 08:29:49 +1000 Subject: [CMake] Use interface libraries for providing compile options and definitions In-Reply-To: References: Message-ID: On Fri, Oct 4, 2019 at 2:27 AM Dustyn Blasig wrote: > Hi All, > > I have been cleaning up our legacy CMake to use newer features (available > in 3.12+) including trying to use target_...() functions nearly > exclusively. As part of this, I was toying with cleaning up our use cases > for adding compiler flags and similar definitions using real targets and > target_link_libraries. > > For instance, as a simple example, let's say I wanted to add/provide a > definition MY_FLAG, I could do something like... > > ``` > add_library(my_flag INTERFACE) > target_compile_definitions(my_flag INTERFACE MY_FLAG=1) > > add_library(other_library SHARED ...) > target_link_libraries(other_library ... *PRIVATE *my_flag) > > export/install rules > ``` > > I want this library to be private to my component, and it's only used > under the PRIVATE banner. However, the issue I'm running into is with the > install/export rules. I get an error similar to ... > > ``` > CMake Error: install(EXPORT "MY_PROJECT" ...) includes target > "other_library" which requires target "my_flag" that is not in the export > set. > ``` > > If my_flag is defined in my component, I can add it to the export set > perhaps to workaround the issue, but in many cases, it would be coming from > a helper script in another sub-project I'm fetching using FetchContent and > don't want to expose the functionality via my export scripts. > > (1) Is it recommended to use interface libraries to clean up compile > defintions, etc. > Personally, I don't typically use interface libraries to do this, I prefer to list the requirements directly on the targets that they apply to. Some people/projects may choose to collect a commonly used set of requirements into an interface library, but one drawback with that is it creates the temptation to lump a bunch of things together in that interface library "for convenience", but end up with some targets having requirements applied to them that aren't actually requirements for those targets at all. Used appropriately, the technique can be helpful, but don't over-use it. ;) > (2) Should it be possible to link privately such libraries and not have > the export functionality complain? > >From a usage requirement point of view, the interface library shouldn't need to be exported/installed because it is private. However, from a linking point of view, a shared library still needs all other libraries it links against for the linker to succeed at link time. Interface libraries don't appear on the linker command line, so they shouldn't need to be installed for linking to succeed, but I'm wondering if CMake's internal logic isn't properly handling this. Can you open an issue in CMake's gitlab and attach a complete, minimal example which reproduces the error (seems you're almost there with the extracted commands above)? -- 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 alexander.samoylov at gmail.com Fri Oct 4 10:45:22 2019 From: alexander.samoylov at gmail.com (Alexander) Date: Fri, 4 Oct 2019 16:45:22 +0200 Subject: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS Message-ID: Hello, I would like to add an extra .defs file for linking of a DLL on Windows. I want to use the CMake command line option -DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the automatically generated /bin/.dir/Release/exports.def i see additionally /DEF:my_defs.defs in the resulting linking command, but it does not happen. What is especially irritating that CMake deliberately removes namely /DEF: from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I write /DEF111:my_defs.def for example) are accepted and I see them the linking command. I tried to reach the same goal using a CMakeLists.txt like this: set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def") but it did not help - the same way CMake removes my /DEF: option. Could you please open a ticket to fix this behavior to not cut /DEF: option from CMAKE_***_LINKER_FLAGS? On my opinion CMake should not interpret or modify the content of CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user specified it. If you have another opinion, please provide any other possibility to pass an arbitrary arguments to the linking command "as is" so that they are not modified. Any workaround is highly appreciated (better command-line, because we build 3rd party software and it would not really fine to change CMakeLists.txt) -- Best Regards, Alexander Samoilov Build & Integration Engineer Compart AG, 71034 B?blingen Germany -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.adam at gmail.com Fri Oct 4 10:53:56 2019 From: cristian.adam at gmail.com (Cristian Adam) Date: Fri, 4 Oct 2019 16:53:56 +0200 Subject: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS In-Reply-To: References: Message-ID: Hi, You should simply add the my_defs.def file as a source files to add_library/add_executable. CMake will automagically pass /DEF: to the linker with my_defs.def Cheers, Cristian. On Fri, Oct 4, 2019 at 4:45 PM Alexander wrote: > Hello, > > I would like to add an extra .defs file for linking of a DLL on Windows. I > want to use the CMake command line option > -DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the > automatically generated > /bin/.dir/Release/exports.def i see additionally > /DEF:my_defs.defs in the resulting linking command, but it does not happen. > > What is especially irritating that CMake deliberately removes namely /DEF: > from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I write > /DEF111:my_defs.def for example) are accepted and I see them the linking > command. > > I tried to reach the same goal using a CMakeLists.txt like this: > > set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def") > > but it did not help - the same way CMake removes my /DEF: option. > > Could you please open a ticket to fix this behavior to not cut /DEF: > option from CMAKE_***_LINKER_FLAGS? > > On my opinion CMake should not interpret or modify the content of > CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user > specified it. If you have another opinion, please provide any other > possibility to pass an arbitrary arguments to the linking command "as is" > so that they are not modified. > > Any workaround is highly appreciated (better command-line, because we > build 3rd party software and it would not really fine to change > CMakeLists.txt) > > -- > Best Regards, > Alexander Samoilov > Build & Integration Engineer > Compart AG, 71034 B?blingen Germany > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.samoylov at gmail.com Fri Oct 4 10:59:34 2019 From: alexander.samoylov at gmail.com (Alexander) Date: Fri, 4 Oct 2019 16:59:34 +0200 Subject: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS In-Reply-To: References: Message-ID: Dear Cristian, It would better for me not modifying CMakeFiles.txt, because as I wrote it is 3rd party stuff (we just download it and build, but some different way). My concern is why the command line option -DCMAKE_SHARED_LINKER_FLAGS deliberately ignores /DEF: option. It this behavior expected? What is the logic behind this behavior? Why not simply allow /DEF in CMAKE_SHARED_LINKER_FLAGS and not cut it? -- Best Regards, Alexander On Fri, 4 Oct 2019 at 16:54, Cristian Adam wrote: > Hi, > > You should simply add the my_defs.def file as a source files to > add_library/add_executable. > CMake will automagically pass /DEF: to the linker with my_defs.def > > Cheers, > Cristian. > > On Fri, Oct 4, 2019 at 4:45 PM Alexander > wrote: > >> Hello, >> >> I would like to add an extra .defs file for linking of a DLL on Windows. >> I want to use the CMake command line option >> -DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the >> automatically generated >> /bin/.dir/Release/exports.def i see additionally >> /DEF:my_defs.defs in the resulting linking command, but it does not happen. >> >> What is especially irritating that CMake deliberately removes namely >> /DEF: from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I >> write /DEF111:my_defs.def for example) are accepted and I see them the >> linking command. >> >> I tried to reach the same goal using a CMakeLists.txt like this: >> >> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def") >> >> but it did not help - the same way CMake removes my /DEF: option. >> >> Could you please open a ticket to fix this behavior to not cut /DEF: >> option from CMAKE_***_LINKER_FLAGS? >> >> On my opinion CMake should not interpret or modify the content of >> CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user >> specified it. If you have another opinion, please provide any other >> possibility to pass an arbitrary arguments to the linking command "as is" >> so that they are not modified. >> >> Any workaround is highly appreciated (better command-line, because we >> build 3rd party software and it would not really fine to change >> CMakeLists.txt) >> >> -- >> Best Regards, >> Alexander Samoilov >> Build & Integration Engineer >> Compart AG, 71034 B?blingen Germany >> -- >> >> 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at seefeld.name Fri Oct 4 14:20:53 2019 From: stefan at seefeld.name (stefan) Date: Fri, 4 Oct 2019 14:20:53 -0400 Subject: [CMake] HOWTO declare component inter-dependencies in multi-component packages In-Reply-To: <1570137876.3676.12.camel@kitware.com> References: <1570134227.3676.9.camel@kitware.com> <03301e84-711f-0d07-410a-d8d955e96ae7@seefeld.name> <1570135030.3676.10.camel@kitware.com> <1570136386.3676.11.camel@kitware.com> <1570137876.3676.12.camel@kitware.com> Message-ID: On 2019-10-03 5:24 p.m., Kyle Edwards wrote: > On Thu, 2019-10-03 at 17:08 -0400, stefan wrote: >> Yes, that is exactly what I'm trying to do, but it doesn't seem to >> have any effect. That is, `dpkg --info ...` doesn't list the >> additional dependency, and correspondingly, running `apt-get install >> ...` on the component package file will install the package without >> first installing the prerequisite component. >> Consider this declaration: >> ? set(CPACK_COMPONENTS_ALL runtime development mstool) >> If I now write >> ? set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS runtime) >> I will see no effect. That is, the "development" package still does >> not depend on the "runtime" package. >> So I try this: >> ? set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS RUNTIME) >> in case capitalization is required. Now the "runtime" component seems >> to get packaged twice (as per the cmake logs), but still no correct >> dependencies. >> Is it time for a bug report ? > Please send us a minimal CMakeLists.txt that reproduces the issue. Sure. Here it is. The relevant line part is line 5. Please let me know what I'm doing wrong. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 1478 bytes Desc: not available URL: -------------- next part -------------- project(demo) set(CPACK_GENERATOR "DEB") set(CPACK_DEBIAN_PACKAGE_MAINTAINER "joe random") set(CPACK_COMPONENTS_ALL runtime dev) set(CPACK_COMPONENT_DEV_DEPENDS runtime) # <- this line doesn't seem to have any effect set(CPACK_DEB_COMPONENT_INSTALL ON) set(CPACK_DEBIAN_FILE_NAME DEB-DEFAULT) include(CPack) file(WRITE a "runtime") file(WRITE b "dev") install(FILES a DESTINATION share COMPONENT runtime) install(FILES b DESTINATION share COMPONENT dev) From dustyn at blasig.us Fri Oct 4 14:30:16 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Fri, 4 Oct 2019 13:30:16 -0500 Subject: [CMake] Use interface libraries for providing compile options and definitions In-Reply-To: References: Message-ID: Thanks for the input. I will try to upload an example soon and upload an issue. In the meantime, I think I'll go the route of providing a library of helper functions like `add_my_flag_target_definitions(other_library PRIVATE)` that any targets can call. It ends up being about the same amount of CMake code and doesn't run into the installation issues. If a client wants to bundle more of them together, they can simply create their own `add_my_superset_of_target_definitions(my_lib PRIVATE)` or something similar that calls all the other functions as needed. On Thu, Oct 3, 2019 at 5:30 PM Craig Scott wrote: > > > On Fri, Oct 4, 2019 at 2:27 AM Dustyn Blasig wrote: > >> Hi All, >> >> I have been cleaning up our legacy CMake to use newer features (available >> in 3.12+) including trying to use target_...() functions nearly >> exclusively. As part of this, I was toying with cleaning up our use cases >> for adding compiler flags and similar definitions using real targets and >> target_link_libraries. >> >> For instance, as a simple example, let's say I wanted to add/provide a >> definition MY_FLAG, I could do something like... >> >> ``` >> add_library(my_flag INTERFACE) >> target_compile_definitions(my_flag INTERFACE MY_FLAG=1) >> >> add_library(other_library SHARED ...) >> target_link_libraries(other_library ... *PRIVATE *my_flag) >> >> export/install rules >> ``` >> >> I want this library to be private to my component, and it's only used >> under the PRIVATE banner. However, the issue I'm running into is with the >> install/export rules. I get an error similar to ... >> >> ``` >> CMake Error: install(EXPORT "MY_PROJECT" ...) includes target >> "other_library" which requires target "my_flag" that is not in the export >> set. >> ``` >> >> If my_flag is defined in my component, I can add it to the export set >> perhaps to workaround the issue, but in many cases, it would be coming from >> a helper script in another sub-project I'm fetching using FetchContent and >> don't want to expose the functionality via my export scripts. >> >> (1) Is it recommended to use interface libraries to clean up compile >> defintions, etc. >> > > Personally, I don't typically use interface libraries to do this, I prefer > to list the requirements directly on the targets that they apply to. Some > people/projects may choose to collect a commonly used set of requirements > into an interface library, but one drawback with that is it creates the > temptation to lump a bunch of things together in that interface library > "for convenience", but end up with some targets having requirements applied > to them that aren't actually requirements for those targets at all. Used > appropriately, the technique can be helpful, but don't over-use it. ;) > > > >> (2) Should it be possible to link privately such libraries and not have >> the export functionality complain? >> > > From a usage requirement point of view, the interface library shouldn't > need to be exported/installed because it is private. However, from a > linking point of view, a shared library still needs all other libraries it > links against for the linker to succeed at link time. Interface libraries > don't appear on the linker command line, so they shouldn't need to be > installed for linking to succeed, but I'm wondering if CMake's internal > logic isn't properly handling this. Can you open an issue in CMake's > gitlab and attach a > complete, minimal example which reproduces the error (seems you're almost > there with the extracted commands above)? > > -- > 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 Oct 5 04:33:25 2019 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 5 Oct 2019 18:33:25 +1000 Subject: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS In-Reply-To: References: Message-ID: On Sat, Oct 5, 2019 at 12:59 AM Alexander wrote: > Dear Cristian, > > It would better for me not modifying CMakeFiles.txt, because as I wrote it > is 3rd party stuff (we just download it and build, but some different way). > My concern is why the command line option -DCMAKE_SHARED_LINKER_FLAGS > deliberately ignores /DEF: option. It this behavior expected? What is the > logic behind this behavior? Why not simply allow /DEF in > CMAKE_SHARED_LINKER_FLAGS and not cut it? > You don't have to modify the third party CMakeLists.txt file to achieve what Cristian suggested. You can call target_sources() on the third party target from your own CMakeLists.txt file to add .def files to their target. You don't have to be in the same directory scope as the target to use target_sources() on it. I'm not familiar with why CMake is stripping out the /DEF: option in your case, but I suspect it would be related to the way CMake expects to add such options based on .def files given as sources. > On Fri, 4 Oct 2019 at 16:54, Cristian Adam > wrote: > >> Hi, >> >> You should simply add the my_defs.def file as a source files to >> add_library/add_executable. >> CMake will automagically pass /DEF: to the linker with my_defs.def >> >> Cheers, >> Cristian. >> >> On Fri, Oct 4, 2019 at 4:45 PM Alexander >> wrote: >> >>> Hello, >>> >>> I would like to add an extra .defs file for linking of a DLL on Windows. >>> I want to use the CMake command line option >>> -DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the >>> automatically generated >>> /bin/.dir/Release/exports.def i see additionally >>> /DEF:my_defs.defs in the resulting linking command, but it does not happen. >>> >>> What is especially irritating that CMake deliberately removes namely >>> /DEF: from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I >>> write /DEF111:my_defs.def for example) are accepted and I see them the >>> linking command. >>> >>> I tried to reach the same goal using a CMakeLists.txt like this: >>> >>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def") >>> >>> but it did not help - the same way CMake removes my /DEF: option. >>> >>> Could you please open a ticket to fix this behavior to not cut /DEF: >>> option from CMAKE_***_LINKER_FLAGS? >>> >>> On my opinion CMake should not interpret or modify the content of >>> CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user >>> specified it. If you have another opinion, please provide any other >>> possibility to pass an arbitrary arguments to the linking command "as is" >>> so that they are not modified. >>> >>> Any workaround is highly appreciated (better command-line, because we >>> build 3rd party software and it would not really fine to change >>> CMakeLists.txt) >>> >>> -- >>> Best Regards, >>> Alexander Samoilov >>> Build & Integration Engineer >>> Compart AG, 71034 B?blingen Germany >>> >> -- 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 ryan.edward.mcclue at protonmail.com Sat Oct 5 23:09:55 2019 From: ryan.edward.mcclue at protonmail.com (Ryan Edward McClue) Date: Sun, 06 Oct 2019 03:09:55 +0000 Subject: [CMake] Using lld on windows Message-ID: To avoid repetition, please view: https://stackoverflow.com/questions/58253100/how-to-use-lld-with-cmake-on-windows Sent with [ProtonMail](https://protonmail.com) Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.turner at kdab.com Mon Oct 7 06:02:08 2019 From: james.turner at kdab.com (James Turner) Date: Mon, 7 Oct 2019 11:02:08 +0100 Subject: [CMake] CMP0093 behaviour Message-ID: Hello, I?m experiencing an odd problem where no matter how I set CMP0093, it seems to use the ?NEW? behaviour, breaking some other code relying on the OLD behaviour. This is Cmake 3.15.4 from Homebrew, other people do report on other platforms do report the policy working for them. Here?s my code to set the policy, in the same place we set other policy options: if(POLICY CMP0093) message(STATUS "Using old Boost version policy") cmake_policy(SET CMP0093 OLD) endif() The message is printed correctly, but after running find_package(Boost?), the value of Boost_VERSION is the new dotted syntax (eg 1.71.0) rather than the old, compatible syntax I need. Is there anything special about this policy where I might have screwed this up? I can?t really imagine it?s a Homebrew packaging issue, but also don?t understand what else I could have gotten wrong syntactically. Kind regards, James From Sebastian.Setzer at de.bosch.com Mon Oct 7 06:24:28 2019 From: Sebastian.Setzer at de.bosch.com (Setzer Sebastian (CM-CI2/ECS2)) Date: Mon, 7 Oct 2019 10:24:28 +0000 Subject: [CMake] DEPENDS parameter of add_custom_target Message-ID: <090a45e217f4497698af806deac88065@de.bosch.com> Dear list, The manual says: https://cmake.org/cmake/help/latest/command/add_custom_target.html Reference files and outputs of custom commands created with add_custom_command() command calls in the same directory (CMakeLists.txt file). They will be brought up to date when the target is built. Use the add_dependencies() command to add dependencies on other targets. This is different from what the manual of add_custom_command says, and would be surprising for all users who only read the manual of add_custom_command and then think they know what the parameter means for add_custom_target. But on the other hand, when I test with this: -------------------------------------------------- cmake_minimum_required (VERSION 3.14) project(dependency_test LANGUAGES) add_custom_target(T1 COMMAND echo T1 ) add_custom_target(T2 COMMAND echo T2 DEPENDS T1 ) # cmake -GNinja -B build . # ninja T2 -------------------------------------------------- Then T1 and T2 are built, so contrary to what the manual says, it seems to work. Is the manual just outdated (Maybe behavior has changed and only manual for add_custom_command has been updated)? Should it be the same as for add_custom_command, or are there really some differences? Regards, Sebastian From craig.scott at crascit.com Mon Oct 7 06:55:37 2019 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 7 Oct 2019 21:55:37 +1100 Subject: [CMake] DEPENDS parameter of add_custom_target In-Reply-To: <090a45e217f4497698af806deac88065@de.bosch.com> References: <090a45e217f4497698af806deac88065@de.bosch.com> Message-ID: On Mon, Oct 7, 2019 at 9:32 PM Setzer Sebastian (CM-CI2/ECS2) via CMake < cmake at cmake.org> wrote: > Dear list, > The manual says: > https://cmake.org/cmake/help/latest/command/add_custom_target.html > Reference files and outputs of custom commands created with > add_custom_command() command calls in the same directory (CMakeLists.txt > file). They will be brought up to date when the target is built. > Use the add_dependencies() command to add dependencies on other targets. > > This is different from what the manual of add_custom_command says, and > would be surprising for all users who only read the manual of > add_custom_command and then think they know what the parameter means for > add_custom_target. > > But on the other hand, when I test with this: > -------------------------------------------------- > cmake_minimum_required (VERSION 3.14) > project(dependency_test LANGUAGES) > > add_custom_target(T1 > COMMAND echo T1 > ) > add_custom_target(T2 > COMMAND echo T2 > DEPENDS T1 > ) > > # cmake -GNinja -B build . > # ninja T2 > -------------------------------------------------- > Then T1 and T2 are built, so contrary to what the manual says, it seems to > work. > > Is the manual just outdated (Maybe behavior has changed and only manual > for add_custom_command has been updated)? > Should it be the same as for add_custom_command, or are there really some > differences? > As it happens, I just updated the docs for these in the last day or so. You can find it in the not-yet-merged merge request here: https://gitlab.kitware.com/cmake/cmake/merge_requests/3891 I wrote an explanation of the specific behavior of the dependencies in the associated issue here: https://gitlab.kitware.com/cmake/cmake/issues/19771#note_635547 There is a difference between the two, but it's subtle and specific to the sort of scenario I mentioned in that issue comment. -- 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 fdk17 at ftml.net Mon Oct 7 08:16:28 2019 From: fdk17 at ftml.net (Fred Baksik) Date: Mon, 07 Oct 2019 08:16:28 -0400 Subject: [CMake] DEPENDS parameter of add_custom_target In-Reply-To: References: <090a45e217f4497698af806deac88065@de.bosch.com> Message-ID: <97612bb9-7f02-4f6e-9b91-8bc02079e1c2@www.fastmail.com> On Mon, Oct 7, 2019, at 6:55 AM, Craig Scott wrote: > > > On Mon, Oct 7, 2019 at 9:32 PM Setzer Sebastian (CM-CI2/ECS2) via CMake wrote: >> Dear list, >> The manual says: >> https://cmake.org/cmake/help/latest/command/add_custom_target.html >> Reference files and outputs of custom commands created with add_custom_command() command calls in the same directory (CMakeLists.txt file). They will be brought up to date when the target is built. >> Use the add_dependencies() command to add dependencies on other targets. >> >> This is different from what the manual of add_custom_command says, and would be surprising for all users who only read the manual of add_custom_command and then think they know what the parameter means for add_custom_target. >> >> But on the other hand, when I test with this: >> -------------------------------------------------- >> cmake_minimum_required (VERSION 3.14) >> project(dependency_test LANGUAGES) >> >> add_custom_target(T1 >> COMMAND echo T1 >> ) >> add_custom_target(T2 >> COMMAND echo T2 >> DEPENDS T1 >> ) >> >> # cmake -GNinja -B build . >> # ninja T2 >> -------------------------------------------------- >> Then T1 and T2 are built, so contrary to what the manual says, it seems to work. >> >> Is the manual just outdated (Maybe behavior has changed and only manual for add_custom_command has been updated)? >> Should it be the same as for add_custom_command, or are there really some differences? > > As it happens, I just updated the docs for these in the last day or so. You can find it in the not-yet-merged merge request here: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/3891 > > I wrote an explanation of the specific behavior of the dependencies in the associated issue here: > > https://gitlab.kitware.com/cmake/cmake/issues/19771#note_635547 > > There is a difference between the two, but it's subtle and specific to the sort of scenario I mentioned in that issue comment. > > -- > 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 > -- > > 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 I found the wording for add_custom_command and add_custom_target to be confusing and had to look at examples (and books) to understand it better. The DEPENDS field is kind of different for the two commands. It may be that add_custom_target "DEPENDS" can accept other custom targets; it seems from your example it does (which wouldn't surprise me from what I remember from the CMake source code). For add_custom_target: The phrase "They will be brought up to date when the target is built." had me thinking that this was going to force the custom command to always run. Its more of a "The commands of add_custom_target() outputs will be run as needed before any add_custom_target() commands are run." If a file listed in DEPENDS does not exist on disk then behavior is defined by the build tool and may or may not throw an error. I recall that Make and Ninja throws errors and MSBuild will have a warning. Then there is the SOURCES field which acts like: Similar to ``DEPENDS`` with the addition that the specified files are checked to exist on disk and will be added to IDE project files for convenience in editing. "add_custom_target() sometimes builds SOURCES for Visual Studio generators but never for Makefiles" https://gitlab.kitware.com/cmake/cmake/issues/10360 For add_custom_command it acts like (and this includes the trick that is used to make it always run): If ``DEPENDS`` is not specified the command will run whenever the ``OUTPUT`` is missing or it will run whenever a file-level dependency is updated. If the command does not create one of the listed ``OUTPUT`` then the rule will always run. For example defining an output file called ALL or FORCE that is never created. Then for the add_custom_command signature that is used for build events. You don't need to put the event. It defaults to POST_BUILD. This is different from the documentation that shows it is a required field. -- Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sebastian.Setzer at de.bosch.com Mon Oct 7 08:21:50 2019 From: Sebastian.Setzer at de.bosch.com (Setzer Sebastian (CM-CI2/ECS2)) Date: Mon, 7 Oct 2019 12:21:50 +0000 Subject: [CMake] DEPENDS parameter of add_custom_target In-Reply-To: References: <090a45e217f4497698af806deac88065@de.bosch.com> Message-ID: <632a53a592f54125afd330fb306fe207@de.bosch.com> Hi Craig, On Mon, 7. Oct 2019 12:56 Craig Scott wrote: > As it happens, I just updated the docs for these in the last day or so. You mean you updated the docs of the two commands, but you did not update the docs of the DEPENDS parameter, right? > There is a difference between the two, but it's subtle and specific to the sort of scenario I mentioned in that issue comment. So the manual for the DEPENDS parameter of add_custom_target is outdated, but fixing it is not as easy as copying it from add_custom_command. Regards, Sebastian From: Craig Scott Sent: Montag, 7. Oktober 2019 12:56 To: Setzer Sebastian (CM-CI2/ECS2) Cc: cmake at cmake.org Subject: Re: [CMake] DEPENDS parameter of add_custom_target On Mon, Oct 7, 2019 at 9:32 PM Setzer Sebastian (CM-CI2/ECS2) via CMake wrote: Dear list, The manual says: https://cmake.org/cmake/help/latest/command/add_custom_target.html Reference files and outputs of custom commands created with add_custom_command() command calls in the same directory (CMakeLists.txt file). They will be brought up to date when the target is built. Use the add_dependencies() command to add dependencies on other targets. This is different from what the manual of add_custom_command says, and would be surprising for all users who only read the manual of add_custom_command and then think they know what the parameter means for add_custom_target. But on the other hand, when I test with this: -------------------------------------------------- cmake_minimum_required (VERSION 3.14) project(dependency_test LANGUAGES) add_custom_target(T1 ? ? ? ? ? ? ? ? ? COMMAND echo T1 ? ? ? ? ? ? ? ? ? ) add_custom_target(T2 ? ? ? ? ? ? ? ? ? COMMAND echo T2 ? ? ? ? ? ? ? ? ? DEPENDS T1 ? ? ? ? ? ? ? ? ? ) # cmake -GNinja -B build . # ninja T2 -------------------------------------------------- Then T1 and T2 are built, so contrary to what the manual says, it seems to work. Is the manual just outdated (Maybe behavior has changed and only manual for add_custom_command has been updated)? Should it be the same as for add_custom_command, or are there really some differences? As it happens, I just updated the docs for these in the last day or so. You can find it in the not-yet-merged merge request here: https://gitlab.kitware.com/cmake/cmake/merge_requests/3891 I wrote an explanation of the specific behavior of the dependencies in the associated issue here: https://gitlab.kitware.com/cmake/cmake/issues/19771#note_635547 There is a difference between the two, but it's subtle and specific to the sort of scenario I mentioned in that issue comment. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user:?https://crascit.com/professional-cmake/ Consulting services (CMake, C++, build/release processes): https://crascit.com/services From craig.scott at crascit.com Mon Oct 7 08:28:14 2019 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 7 Oct 2019 23:28:14 +1100 Subject: [CMake] DEPENDS parameter of add_custom_target In-Reply-To: <632a53a592f54125afd330fb306fe207@de.bosch.com> References: <090a45e217f4497698af806deac88065@de.bosch.com> <632a53a592f54125afd330fb306fe207@de.bosch.com> Message-ID: On Mon, Oct 7, 2019 at 11:21 PM Setzer Sebastian (CM-CI2/ECS2) < Sebastian.Setzer at de.bosch.com> wrote: > Hi Craig, > > On Mon, 7. Oct 2019 12:56 Craig Scott wrote: > > As it happens, I just updated the docs for these in the last day or so. > > You mean you updated the docs of the two commands, but you did not update > the docs of the DEPENDS parameter, right? > Yes, sorry if that was only partially related to your original query. Fred's follow-up makes it clearer that the wording of a few sections for these two commands probably need some improvement (that will be separate to the merge request I linked to). > > There is a difference between the two, but it's subtle and specific to > the sort of scenario I mentioned in that issue comment. > > So the manual for the DEPENDS parameter of add_custom_target is outdated, > but fixing it is not as easy as copying it from add_custom_command. > I'll defer a response on whether it is outdated or not, but I would expect different text to be required for the two commands because they do have different behaviours. From: Craig Scott > Sent: Montag, 7. Oktober 2019 12:56 > To: Setzer Sebastian (CM-CI2/ECS2) > Cc: cmake at cmake.org > Subject: Re: [CMake] DEPENDS parameter of add_custom_target > > > > On Mon, Oct 7, 2019 at 9:32 PM Setzer Sebastian (CM-CI2/ECS2) via CMake > wrote: > Dear list, > The manual says: > https://cmake.org/cmake/help/latest/command/add_custom_target.html > Reference files and outputs of custom commands created with > add_custom_command() command calls in the same directory (CMakeLists.txt > file). They will be brought up to date when the target is built. > Use the add_dependencies() command to add dependencies on other targets. > > This is different from what the manual of add_custom_command says, and > would be surprising for all users who only read the manual of > add_custom_command and then think they know what the parameter means for > add_custom_target. > > But on the other hand, when I test with this: > -------------------------------------------------- > cmake_minimum_required (VERSION 3.14) > project(dependency_test LANGUAGES) > > add_custom_target(T1 > COMMAND echo T1 > ) > add_custom_target(T2 > COMMAND echo T2 > DEPENDS T1 > ) > > # cmake -GNinja -B build . > # ninja T2 > -------------------------------------------------- > Then T1 and T2 are built, so contrary to what the manual says, it seems to > work. > > Is the manual just outdated (Maybe behavior has changed and only manual > for add_custom_command has been updated)? > Should it be the same as for add_custom_command, or are there really some > differences? > > As it happens, I just updated the docs for these in the last day or so. > You can find it in the not-yet-merged merge request here: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/3891 > > I wrote an explanation of the specific behavior of the dependencies in the > associated issue here: > > https://gitlab.kitware.com/cmake/cmake/issues/19771#note_635547 > > There is a difference between the two, but it's subtle and specific to the > sort of scenario I mentioned in that issue comment. > -- 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 v.van.beveren at nikhef.nl Mon Oct 7 08:35:55 2019 From: v.van.beveren at nikhef.nl (Vincent van Beveren) Date: Mon, 7 Oct 2019 14:35:55 +0200 Subject: [CMake] Adding CRC32 to ELF Message-ID: <75094023-8da1-a9ba-fb10-9b4b44feb8d7@nikhef.nl> Hello everyone, I'm setting up a new build targeting an embedded platform (LM32) and trying to integrate a CRC32 into the resulting ELF. I have previously done this using plain Makefiles with the following steps (pseudo code): target.elf: ?? link --symbol CRC_VALUE=0 intermediate.elf ?? objcopy --binary intermediate.elf intermediate.bin ?? link --symbol CRC_VALUE=`crc32 intermediate.bin` target.elf ?? rm intermediate.bin Now I would like to achieve the same thing with CMake. I'm using add_executable with multiple targets. The end of my CMakeLists.txt looks like this, where F_GEN contains generic source files and F__* source files specific for that variant of the build: # [...defining of cross compiler, and source files, some compile flags, etc...] # Educate the linker add_link_options( ??? -nostartfiles ??? -nodefaultlibs ??? -nostdlib ??? -Wl,--gc-sections ??? -T ${CMAKE_SOURCE_DIR}/${P_SRC}/romram.ld ??? -Wl,--defsym=CRC_VALUE=0 ??? -Wl,--defsym=_start=0 ??? ) # DOM v2 target add_executable( clb_v2_dom.elf ${F_GEN} ${F__DOM} ) target_compile_definitions(clb_v2_dom.elf PUBLIC -DDOM -DCLBV2 ) # BASE v2 target add_executable( clb_v2_base.elf ${F_GEN} ${F__BASE} ) # TODO migrate define 'DUBASE' -> 'BASE' target_compile_definitions(clb_v2_base.elf PUBLIC -DDUBASE -DBASE -DCLBV2) # Golden v2 target add_executable( clb_v2_golden.elf ${F_GEN} ${F__GLD} ) target_compile_definitions( clb_v2_golden.elf PUBLIC -DGOLDEN -DCLBV2 ) == As you can see CRC_VALUE is now simply defined 0 for every target. Which works well for compiling but during runtime poses a problem to the ROM verification procedure. What would a 'proper' way be of adding a CRC to an ELF file be using CMake, and be different for each target. Any help is welcome! Kind regards, Vincent -- National Institute for Subatomic Physics Nikhef Department of Computer Technology Science Park 105 1098 XG AMSTERDAM tel. : +31 (0)20 592 2032 e-mail: v.van.beveren at nikhef.nl site : http://www.nikhef.nl/~vincentb From cornelis at bockemuehl.ch Mon Oct 7 09:44:02 2019 From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=) Date: Mon, 07 Oct 2019 15:44:02 +0200 Subject: [CMake] =?utf-8?q?Looking_for_an_explanation=3A_What_exactly_mea?= =?utf-8?q?ns_=22install=22_in_cmake_language=3F?= Message-ID: <718-5d9b4100-29-67597200@248010462> Constantly I am stumbling over the word "install" in the context of cmake scripts - while it is pretty clear that the word cannot mean what nowadays people would understand by that term! But even reading the docs forwards and backwards, studying examples and some generic cmake tutorials I still do hot have a PRECISE idea about what it is actually doing and what the purpose is. Well, I can see everywhere HOW it is done - but it is sometimes an advantage if you also know WHAT! I know that this question is probably so stupid that I do not really expect anybody to answer it here in the mailing list, but maybe somebody can point me to a resource that explains it in a language that a "mere mortal programmer" can follow? So far I have a certain kind of understanding, and sometimes it looks like this is correct, but then again I have my certain doubts. I am using install(TARGETS), install(FILES) and install(EXPORT) so far, and the way I am doing it I mostly picked from some general intros and tutorials. And from what I understand, this is what I expect to happen: install(FILES): some files are copied from some location in the build tree to some installation location install(EXPORT): some cmake script is written that a "derived" project can call (through find_package) in order to get knowledge about my project install(TARGET): not really an idea what should happen: also some copying from build tree to installation tree I suppose Now I also learned that the install step does not happen during a normal build "all" - like "ninja all", but requires an extra "ninja install" step. And also I saw that you can adapt the target of the installation process like this in your project - if you never ever expect the build to be "installed" anywhere else: set(CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_BINARY_DIR}/../install CACHE PATH "" FORCE) With this I would expect to generate an install folder in parallel to the bin, lib64 and other folders in the build tree, collecting there all the "products" of the build for further processing by a derived project. But what I see is actually - almost nothing! Well, the install(FILES) actually copies a file, and the install(EXPORT) indeed generates a cmake script, but from the install(TARGET) I see no effect: the install folder remains completely empty! Still I see in the log many things like "Installing: /.../install/bin/" - but I never find then in that indicated location. But yes, it said "installing", not "copying" - so I am back to my initial question: what the hell is "installing" in cmake language? So basically my problem is: I cannot judge whether my script is working because I simply do not know what SHOULD be the effect of install(TARGET)! Ah yes, my build tree is after a "normal build" ("all", not "install") full of cmake_install.cmake files that would probably have something to do with that "installation" process, but what? Am I supposed to call them on any occasion or are they supposed to be called automatically at some moment? Finally, I managed to get also some find_package() working for my project. The "heart" of this is a Config.cmake script that I am generating during the project build, and which I can write in whatever way I want. For example, I am reading everywhere that I am supposed to do an install(EXPORT) in order to make that find_package() happen, but since I do not really understand what it is supposed to do, and I also see that I can simply write that Config file in such a way that it picks things from where the build process puts them, I do not really see the point. In other words: I tend to simply write config scripts for the import that rely on the build tree and simply skip that install step - because getting this to work is so difficult if you never know what is supposed to happen how and at what stage of the process and under which conditions! But then I see that others are still using the install() steps, so there is probably still some meaning in it... So IF such a thing exists, like a comprehensive explanation about what "install" actually means and what it is supposed to do at what stage of the process, I would be very happy and thankful! Best regards, Cornelis ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Oct 7 09:55:06 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 7 Oct 2019 15:55:06 +0200 Subject: [CMake] Adding CRC32 to ELF In-Reply-To: <75094023-8da1-a9ba-fb10-9b4b44feb8d7@nikhef.nl> References: <75094023-8da1-a9ba-fb10-9b4b44feb8d7@nikhef.nl> Message-ID: Le lun. 7 oct. 2019 ? 14:41, Vincent van Beveren a ?crit : > Hello everyone, > > I'm setting up a new build targeting an embedded platform (LM32) and > trying to integrate a CRC32 into the resulting ELF. I have previously > done this using plain Makefiles with the following steps (pseudo code): > > target.elf: > link --symbol CRC_VALUE=0 intermediate.elf > objcopy --binary intermediate.elf intermediate.bin > link --symbol CRC_VALUE=`crc32 intermediate.bin` target.elf > rm intermediate.bin > > Now I would like to achieve the same thing with CMake. I'm using > add_executable with multiple targets. The end of my CMakeLists.txt looks > like this, where F_GEN contains generic source files and F__* source > files specific for that variant of the build: > > # [...defining of cross compiler, and source files, some compile flags, > etc...] > # Educate the linker > add_link_options( > -nostartfiles > -nodefaultlibs > -nostdlib > -Wl,--gc-sections > -T ${CMAKE_SOURCE_DIR}/${P_SRC}/romram.ld > -Wl,--defsym=CRC_VALUE=0 > -Wl,--defsym=_start=0 > ) > > # DOM v2 target > add_executable( clb_v2_dom.elf ${F_GEN} ${F__DOM} ) > target_compile_definitions(clb_v2_dom.elf PUBLIC -DDOM -DCLBV2 ) > > # BASE v2 target > add_executable( clb_v2_base.elf ${F_GEN} ${F__BASE} ) > # TODO migrate define 'DUBASE' -> 'BASE' > target_compile_definitions(clb_v2_base.elf PUBLIC -DDUBASE -DBASE -DCLBV2) > > # Golden v2 target > add_executable( clb_v2_golden.elf ${F_GEN} ${F__GLD} ) > target_compile_definitions( clb_v2_golden.elf PUBLIC -DGOLDEN -DCLBV2 ) > > == > > As you can see CRC_VALUE is now simply defined 0 for every target. Which > works well for compiling but during runtime poses a problem to the ROM > verification procedure. What would a 'proper' way be of adding a CRC to > an ELF file be using CMake, and be different for each target. Any help > is welcome! > I would try to add a set of custom command as POST_BUILD event. https://cmake.org/cmake/help/v3.15/command/add_custom_command.html#build-events add_custom_command(TARGET clb_v2_base.elf POST_BUILD COMMAND crc32 $ > $.crc32 COMMAND ${CMAKE_C_COMPILER} --symbol $.crc32 $ ) I don't know if the linker can read the computed crc32 from the previously generated file but you get the idea. Moreover if you want to easily collect objects used for linking a target you may need to use an intermediate OBJECT library in order to be able to retrieve $ see: https://cmake.org/cmake/help/latest/command/add_library.html#object-libraries i.e. replace: add_executable( clb_v2_dom.elf ${F_GEN} ${F__DOM} ) by add_library(clb_v2_dom.objs OBJECT ${F_GEN} ${F__DOM}) add_executable(clb_v2_dom.elf $) and then: add_custom_command(TARGET clb_v2_dom.elf POST_BUILD COMMAND crc32 $ > $.crc32 COMMAND ${CMAKE_C_COMPILER} $ --symbol $.crc32 $ ) If this looks ok to you I would then write my own lm32_add_executable that would wraps this up in order to be called as: lm32_add_executable(EXECUTABLE clb_v2_dom.elf SOURCES ${F_GEN} ${F__DOM}) > Kind regards, > Vincent > > > > -- > National Institute for Subatomic Physics Nikhef > Department of Computer Technology > Science Park 105 > 1098 XG AMSTERDAM > > tel. : +31 (0)20 592 2032 > e-mail: v.van.beveren at nikhef.nl > site : http://www.nikhef.nl/~vincentb > > -- > > 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 > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Mon Oct 7 10:19:57 2019 From: d3ck0r at gmail.com (J Decker) Date: Mon, 7 Oct 2019 07:19:57 -0700 Subject: [CMake] Looking for an explanation: What exactly means "install" in cmake language? In-Reply-To: <718-5d9b4100-29-67597200@248010462> References: <718-5d9b4100-29-67597200@248010462> Message-ID: Install steps are done with `cmake --build . --target install` (or --target INSTALL on some generators) It's done after the build is complete, if the build step fails, it will not install. (Install depends on build automatically) The install steps can also be used by --target package - which you can use a packager to .tar.gz or NSIS(?) Executable or..... It needs some CPACK instructions set. On Mon, Oct 7, 2019 at 6:44 AM Cornelis Bockem?hl wrote: > Constantly I am stumbling over the word "install" in the context of cmake > scripts - while it is pretty clear that the word cannot mean what nowadays > people would understand by that term! But even reading the docs forwards > and backwards, studying examples and some generic cmake tutorials I still > do hot have a PRECISE idea about what it is actually doing and what the > purpose is. Well, I can see everywhere HOW it is done - but it is sometimes > an advantage if you also know WHAT! > > I know that this question is probably so stupid that I do not really > expect anybody to answer it here in the mailing list, but maybe somebody > can point me to a resource that explains it in a language that a "mere > mortal programmer" can follow? > > So far I have a certain kind of understanding, and sometimes it looks like > this is correct, but then again I have my certain doubts. I am using > install(TARGETS), install(FILES) and install(EXPORT) so far, and the way I > am doing it I mostly picked from some general intros and tutorials. And > from what I understand, this is what I expect to happen: > > install(FILES): some files are copied from some location in the build tree > to some installation location > install(EXPORT): some cmake script is written that a "derived" project can > call (through find_package) in order to get knowledge about my project > install(TARGET): not really an idea what should happen: also some copying > from build tree to installation tree I suppose > > Now I also learned that the install step does not happen during a normal > build "all" - like "ninja all", but requires an extra "ninja install" step. > And also I saw that you can adapt the target of the installation process > like this in your project - if you never ever expect the build to be > "installed" anywhere else: > > set(CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_BINARY_DIR}/../install CACHE PATH > "" FORCE) > > With this I would expect to generate an install folder in parallel to the > bin, lib64 and other folders in the build tree, collecting there all the > "products" of the build for further processing by a derived project. > > But what I see is actually - almost nothing! > > Well, the install(FILES) actually copies a file, and the install(EXPORT) > indeed generates a cmake script, but from the install(TARGET) I see no > effect: the install folder remains completely empty! Still I see in the log > many things like "Installing: /.../install/bin/" - but I never > find then in that indicated location. But yes, it said > "installing", not "copying" - so I am back to my initial question: what the > hell is "installing" in cmake language? > > So basically my problem is: I cannot judge whether my script is working > because I simply do not know what SHOULD be the effect of install(TARGET)! > > Ah yes, my build tree is after a "normal build" ("all", not "install") > full of cmake_install.cmake files that would probably have something to do > with that "installation" process, but what? Am I supposed to call them on > any occasion or are they supposed to be called automatically at some moment? > > Finally, I managed to get also some find_package() working for my project. > The "heart" of this is a Config.cmake script that I am generating > during the project build, and which I can write in whatever way I want. For > example, I am reading everywhere that I am supposed to do an > install(EXPORT) in order to make that find_package() happen, but since I do > not really understand what it is supposed to do, and I also see that I can > simply write that Config file in such a way that it picks things from where > the build process puts them, I do not really see the point. > > In other words: I tend to simply write config scripts for the import that > rely on the build tree and simply skip that install step - because getting > this to work is so difficult if you never know what is supposed to happen > how and at what stage of the process and under which conditions! > > But then I see that others are still using the install() steps, so there > is probably still some meaning in it... > > So IF such a thing exists, like a comprehensive explanation about what > "install" actually means and what it is supposed to do at what stage of the > process, I would be very happy and thankful! > > Best regards, > Cornelis > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Oct 7 10:23:53 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 7 Oct 2019 16:23:53 +0200 Subject: [CMake] Looking for an explanation: What exactly means "install" in cmake language? In-Reply-To: <718-5d9b4100-29-67597200@248010462> References: <718-5d9b4100-29-67597200@248010462> Message-ID: I'll try some answer. In order to illustrate my words have a look at this figure: https://raw.githubusercontent.com/dev-cafe/cmake-cookbook/master/figures/cmake-times/cmake-times.jpg 1) When cmake "runs" (both cmake and generation times) you get your build tree configured and populated 2) At build times all build artefact are constructed *in the build tree* somewhere 3) Then when you *install* you copy files/targetd/... from the build tree down to the "install location". The fact that CMake install command are "processed" during 1) does not copy anything before actual [generated] install command are executed during 3). Le lun. 7 oct. 2019 ? 15:44, Cornelis Bockem?hl a ?crit : > Constantly I am stumbling over the word "install" in the context of cmake > scripts - while it is pretty clear that the word cannot mean what nowadays > people would understand by that term! But even reading the docs forwards > and backwards, studying examples and some generic cmake tutorials I still > do hot have a PRECISE idea about what it is actually doing and what the > purpose is. Well, I can see everywhere HOW it is done - but it is sometimes > an advantage if you also know WHAT! > > I know that this question is probably so stupid that I do not really > expect anybody to answer it here in the mailing list, but maybe somebody > can point me to a resource that explains it in a language that a "mere > mortal programmer" can follow? > > So far I have a certain kind of understanding, and sometimes it looks like > this is correct, but then again I have my certain doubts. I am using > install(TARGETS), install(FILES) and install(EXPORT) so far, and the way I > am doing it I mostly picked from some general intros and tutorials. And > from what I understand, this is what I expect to happen: > > install(FILES): some files are copied from some location in the build tree > to some installation location > install(EXPORT): some cmake script is written that a "derived" project can > call (through find_package) in order to get knowledge about my project > install(TARGET): not really an idea what should happen: also some copying > from build tree to installation tree I suppose > > Now I also learned that the install step does not happen during a normal > build "all" - like "ninja all", but requires an extra "ninja install" step. > And also I saw that you can adapt the target of the installation process > like this in your project - if you never ever expect the build to be > "installed" anywhere else: > > set(CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_BINARY_DIR}/../install CACHE PATH > "" FORCE) > > With this I would expect to generate an install folder in parallel to the > bin, lib64 and other folders in the build tree, collecting there all the > "products" of the build for further processing by a derived project. > Nope. CMake will be using the declarative install(...) command and CMAKE_INSTALL_xxx variables values *at CMake times* in order to generate scripts that will be run when you do "ninja install" / "make install". > But what I see is actually - almost nothing! > > Well, the install(FILES) actually copies a file, and the install(EXPORT) > indeed generates a cmake script, but from the install(TARGET) I see no > effect: the install folder remains completely empty! Still I see in the log > many things like "Installing: /.../install/bin/" - but I never > find then in that indicated location. But yes, it said > "installing", not "copying" - so I am back to my initial question: what the > hell is "installing" in cmake language? > Copying some build tree artefact to the specified install location. > So basically my problem is: I cannot judge whether my script is working > because I simply do not know what SHOULD be the effect of install(TARGET)! > > Ah yes, my build tree is after a "normal build" ("all", not "install") > full of cmake_install.cmake files that would probably have something to do > with that "installation" process, but what? Am I supposed to call them on > any occasion or are they supposed to be called automatically at some moment? > cmake_install.cmake are cmake scripts that are executed when you do "ninja install" i.e. when you build the pseudo target "install". > Finally, I managed to get also some find_package() working for my project. > The "heart" of this is a Config.cmake script that I am generating > during the project build, and which I can write in whatever way I want. For > example, I am reading everywhere that I am supposed to do an > install(EXPORT) in order to make that find_package() happen, but since I do > not really understand what it is supposed to do, and I also see that I can > simply write that Config file in such a way that it picks things from where > the build process puts them, I do not really see the point. > > In other words: I tend to simply write config scripts for the import that > rely on the build tree and simply skip that install step - because getting > this to work is so difficult if you never know what is supposed to happen > how and at what stage of the process and under which conditions! > > But then I see that others are still using the install() steps, so there > is probably still some meaning in it... > Your build tree contains absolute path that may not be used to prepare a package (RPM, DEB, or any other binary installer) for which the content should usually be relocatable, i.e. may be installed at another prefix than the one used for your build tree. So IF such a thing exists, like a comprehensive explanation about what > "install" actually means and what it is supposed to do at what stage of the > process, I would be very happy and thankful! > Chapter 25 of Professionnal CMake (https://crascit.com/professional-cmake/) contains many things about that. Chapter 10 of CMake Cookbook ( https://github.com/dev-cafe/cmake-cookbook/tree/master/chapter-10, https://www.packtpub.com/eu/application-development/cmake-cookbook) contains valuable examples as well.. > > Best regards, > Cornelis > -- > > 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 > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis at bockemuehl.ch Mon Oct 7 10:49:19 2019 From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=) Date: Mon, 07 Oct 2019 16:49:19 +0200 Subject: [CMake] =?utf-8?q?=3F=3D=3D=3Futf-8=3Fq=3F__Looking_for_an_expla?= =?utf-8?q?nation=3A_What_exactly_means_=22install=22_in_cmake_language=3F?= In-Reply-To: Message-ID: <718-5d9b5080-2f-67597200@248010465> Thanks to both you and J Decker: I would say that this is still the part that I understood! So basically the word "install" in cmake language could be replaced by "copy" more or less in common human language - right? But then, if it is about "installing" a "target", which is libraries in my case, I would expect the shared libraries to be copied - no? And this is exactly what does not happen - for no obvious reason! Because some days ago it even happened in my project ONCE - and then not any more. But debugging is not easy because since that moment I changed many things, and basically the reason for my question is that I have no clear idea what EXACTLY should happen if I put a install(TARGETS mylibrary) into my CMakeLists.txt. Well, like you explained, and like what I also thought I had understood: nothing should happen during the configure and generate runs of cmake, and also not during the "ninja all" build run, but only during the "ninja install". or else cmake --build . --target install (which in turn calls ninja in my case). Indeed I observed that it does a build for "all" first if the initial project is not up to date. But then it tells me that it is successfully "installing" mylibrary, but I see no shared library appearing in the install tree! Or rather: it happened once, but not any more - and I should find out what is missing... My current workaround is indeed that I am trying to avoid the install step altogether and build a crazy construction with configure_file stuff in order to get the libraries to the right place - and I know pretty well that this is NOT the way how things should be done properly. But I am afraid I will be ready with this workaround way faster than I will understand what is going on during this miraculous "install" process! -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.van.beveren at nikhef.nl Mon Oct 7 11:09:32 2019 From: v.van.beveren at nikhef.nl (Vincent van Beveren) Date: Mon, 7 Oct 2019 17:09:32 +0200 Subject: [CMake] Adding CRC32 to ELF In-Reply-To: References: <75094023-8da1-a9ba-fb10-9b4b44feb8d7@nikhef.nl> Message-ID: <7188cc80-e8e0-45cc-0e01-771ad78bb673@nikhef.nl> Hi Eric, Thanks for your prompt reply. I have been able to follow your steps up until the item, so thanks! ?COMMAND ${CMAKE_C_COMPILER}?$ --symbol?$.crc32 ?$ I ran into two challenges: - The argument '$.crc32' should be the actual content of the file, and not the file itself, i.e. the calculated CRC value.? How to do this? - As far as I can see, non of the previously defined linker flags are added to this command. Of course I can do this, but it would mean I need to define things twice. Cheers, Vincent On 7-10-2019 at 15:55 wrote Eric Noulard: > > > Le?lun. 7 oct. 2019 ??14:41, Vincent van Beveren > > a ?crit?: > > Hello everyone, > > I'm setting up a new build targeting an embedded platform (LM32) and > trying to integrate a CRC32 into the resulting ELF. I have previously > done this using plain Makefiles with the following steps (pseudo > code): > > target.elf: > ??? link --symbol CRC_VALUE=0 intermediate.elf > ??? objcopy --binary intermediate.elf intermediate.bin > ??? link --symbol CRC_VALUE=`crc32 intermediate.bin` > target.elf > ??? rm intermediate.bin > > Now I would like to achieve the same thing with CMake. I'm using > add_executable with multiple targets. The end of my CMakeLists.txt > looks > like this, where F_GEN contains generic source files and F__* source > files specific for that variant of the build: > > # [...defining of cross compiler, and source files, some compile > flags, > etc...] > # Educate the linker > add_link_options( > ???? -nostartfiles > ???? -nodefaultlibs > ???? -nostdlib > ???? -Wl,--gc-sections > ???? -T ${CMAKE_SOURCE_DIR}/${P_SRC}/romram.ld > ???? -Wl,--defsym=CRC_VALUE=0 > ???? -Wl,--defsym=_start=0 > ???? ) > > # DOM v2 target > add_executable( clb_v2_dom.elf ${F_GEN} ${F__DOM} ) > target_compile_definitions(clb_v2_dom.elf PUBLIC -DDOM -DCLBV2 ) > > # BASE v2 target > add_executable( clb_v2_base.elf ${F_GEN} ${F__BASE} ) > # TODO migrate define 'DUBASE' -> 'BASE' > target_compile_definitions(clb_v2_base.elf PUBLIC -DDUBASE -DBASE > -DCLBV2) > > # Golden v2 target > add_executable( clb_v2_golden.elf ${F_GEN} ${F__GLD} ) > target_compile_definitions( clb_v2_golden.elf PUBLIC -DGOLDEN > -DCLBV2 ) > > == > > As you can see CRC_VALUE is now simply defined 0 for every target. > Which > works well for compiling but during runtime poses a problem to the > ROM > verification procedure. What would a 'proper' way be of adding a > CRC to > an ELF file be using CMake, and be different for each target. Any > help > is welcome! > > > I would try to add a set of custom command as POST_BUILD event. > https://cmake.org/cmake/help/v3.15/command/add_custom_command.html#build-events > > add_custom_command(TARGET?clb_v2_base.elf?POST_BUILD > ?COMMAND?crc32?$ > >?$.crc32 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?COMMAND ${CMAKE_C_COMPILER} > --symbol?$.crc32 > ?$ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ) > > I don't know if the linker can read the computed crc32 from the > previously generated file but you get the idea. > Moreover if you want to easily collect objects used for linking a > target you may need to use an intermediate > OBJECT library in order to be able to retrieve?$ > see: > https://cmake.org/cmake/help/latest/command/add_library.html#object-libraries > i.e. replace: > add_executable( clb_v2_dom.elf ${F_GEN} ${F__DOM} ) > > by > add_library(clb_v2_dom.objs OBJECT?${F_GEN} ${F__DOM}) > add_executable(clb_v2_dom.elf $) > > and then: > > add_custom_command(TARGET?clb_v2_dom.elf?POST_BUILD > ?COMMAND?crc32?$ > >?$.crc32 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?COMMAND > ${CMAKE_C_COMPILER}?$ > --symbol?$.crc32 > ?$ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ) > > If this looks ok to you I would then write my own > > lm32_add_executable that would wraps this up in order to be called as: > > lm32_add_executable(EXECUTABLE clb_v2_dom.elf > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?SOURCES?${F_GEN} ${F__DOM}) > > > > > Kind regards, > Vincent > > > > -- > National Institute for Subatomic Physics Nikhef > Department of Computer Technology > Science Park 105 > 1098 XG AMSTERDAM > > tel.? : +31 (0)20 592 2032 > e-mail: v.van.beveren at nikhef.nl > site? : http://www.nikhef.nl/~vincentb > > -- > > 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 > > > > -- > Eric -- National Institute for Subatomic Physics Nikhef Department of Computer Technology Science Park 105 1098 XG AMSTERDAM tel. : +31 (0)20 592 2032 e-mail: v.van.beveren at nikhef.nl site : http://www.nikhef.nl/~vincentb -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Mon Oct 7 11:16:45 2019 From: d3ck0r at gmail.com (J Decker) Date: Mon, 7 Oct 2019 08:16:45 -0700 Subject: [CMake] ?==?utf-8?q? Looking for an explanation: What exactly means "install" in cmake language? In-Reply-To: <718-5d9b5080-2f-67597200@248010465> References: <718-5d9b5080-2f-67597200@248010465> Message-ID: A note - INSTALL( FILES ) is only good for data files, if you have scripts that have executable permissions using INSTALL( PROGRAMS ) will get execute flag set too. On Mon, Oct 7, 2019 at 7:49 AM Cornelis Bockem?hl wrote: > Thanks to both you and J Decker: I would say that this is still the part > that I understood! So basically the word "install" in cmake language could > be replaced by "copy" more or less in common human language - right? > > But then, if it is about "installing" a "target", which is libraries in my > case, I would expect the shared libraries to be copied - no? > > Targets use ,... depending on add_executable, or add_library was used( and/or if STATIC/SHARED is specified in add library ) > And this is exactly what does not happen - for no obvious reason! Because > some days ago it even happened in my project ONCE - and then not any more. > But debugging is not easy because since that moment I changed many things, > and basically the reason for my question is that I have no clear idea what > EXACTLY should happen if I put a > > install(TARGETS mylibrary) > I usally put it immediately after the thing that added the target... > > into my CMakeLists.txt. Well, like you explained, and like what I also > thought I had understood: nothing should happen during the configure and > generate runs of cmake, and also not during the "ninja all" build run, but > only during the "ninja install". or else cmake --build . --target install > (which in turn calls ninja in my case). Indeed I observed that it does a > build for "all" first if the initial project is not up to date. > right, it's an 'install' target.. make install ; ninja install, ... etc ya > > But then it tells me that it is successfully "installing" mylibrary, but I > see no shared library appearing in the install tree! Or rather: it happened > once, but not any more - and I should find out what is missing... > When I have issues like that, `cmake --trace ...` option gives a good idea of what cmake thinks it's doing... or maybe ninja V=1 install ? It is copy-if-different, so if the build re-builds and generates the same output library it won't re-install... You can set set( CMAKE_INSTALL_MESSAGE "LAZY" ) which only emits messages for things it actually installs.... (just a side note) But I don't know why it's not going where you think it is ( somewhere in CMAKE_BINARY_DIR IIRC? or did you use CMAKE_CURRENT_BINARY_DIR which can be deeply in install) I do often set my install to 'output' which by default is put into the build directory... > My current workaround is indeed that I am trying to avoid the install step > altogether and build a crazy construction with configure_file stuff in > order to get the libraries to the right place - and I know pretty well that > this is NOT the way how things should be done properly. But I am afraid I > will be ready with this workaround way faster than I will understand what > is going on during this miraculous "install" process! -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Oct 7 11:25:08 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 7 Oct 2019 17:25:08 +0200 Subject: [CMake] Looking for an explanation: What exactly means "install" in cmake language? In-Reply-To: <718-5d9b5080-2f-67597200@248010465> References: <718-5d9b5080-2f-67597200@248010465> Message-ID: Le lun. 7 oct. 2019 ? 16:49, Cornelis Bockem?hl a ?crit : > Thanks to both you and J Decker: I would say that this is still the part > that I understood! So basically the word "install" in cmake language could > be replaced by "copy" more or less in common human language - right? > Nope I oversimplified. This is not a bare copy, e.g. the runtime path (a.k.a. RPATH or RUNPATH) is updated as well. But then, if it is about "installing" a "target", which is libraries in my > case, I would expect the shared libraries to be copied - no? > Yes the shared lib should be coped and its RPATH updated. > And this is exactly what does not happen - for no obvious reason! Because > some days ago it even happened in my project ONCE - and then not any more. > But debugging is not easy because since that moment I changed many things, > and basically the reason for my question is that I have no clear idea what > EXACTLY should happen if I put a > > install(TARGETS mylibrary) > > into my CMakeLists.txt. Well, like you explained, and like what I also > thought I had understood: nothing should happen during the configure and > generate runs of cmake, and also not during the "ninja all" build run, but > only during the "ninja install". or else cmake --build . --target install > (which in turn calls ninja in my case). Indeed I observed that it does a > build for "all" first if the initial project is not up to date. > > But then it tells me that it is successfully "installing" mylibrary, but I > see no shared library appearing in the install tree! Or rather: it happened > once, but not any more - and I should find out what is missing... > . Are building out-of-tree? (Are your source tree and build tree separate dir?) If so, did you try removing the entire build tree and try again ? May be there is probably some mixup with your install DESTINATION in your install command. > > My current workaround is indeed that I am trying to avoid the install step > altogether and build a crazy construction with configure_file stuff in > order to get the libraries to the right place - and I know pretty well that > this is NOT the way how things should be done properly. But I am afraid I > will be ready with this workaround way faster than I will understand what > is going on during this miraculous "install" process! Provide us with a stripped down non-working example and we may dig into it. Otherwise it is very difficult to guess what is happening in your particular case. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis at bockemuehl.ch Mon Oct 7 11:47:13 2019 From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=) Date: Mon, 07 Oct 2019 17:47:13 +0200 Subject: [CMake] =?utf-8?q?=3F=3D=3D=3Futf-8=3Fq=3F__Looking_for_an_expla?= =?utf-8?q?nation=3A_What_exactly_means_=22install=22_in_cmake_language=3F?= In-Reply-To: Message-ID: <718-5d9b5e00-33-67597200@248010467> >Le lun. 7 oct. 2019 ? 16:49, Cornelis Bockem?hl a ?crit : > >> Thanks to both you and J Decker: I would say that this is still the part >> that I understood! So basically the word "install" in cmake language could >> be replaced by "copy" more or less in common human language - right? > >Nope I oversimplified. >This is not a bare copy, e.g. the runtime path (a.k.a. RPATH or RUNPATH) is >updated as well. Well yes, I understood that there are "some" other things happening - and I did not think about RPATH or RUNPATH - because so far I never cared for them... At this moment I finally have a setup running where shared libraries are simply copied over with configure_file - without care for RPATH etc. -, and it's working finally! But definitely now like the inventors of cmake have thought it should, with a lot reinventing wheels etc... >> But then, if it is about "installing" a "target", which is libraries in my >> case, I would expect the shared libraries to be copied - no? > >Yes the shared lib should be coped and its RPATH updated. > >> And this is exactly what does not happen - for no obvious reason! Because >> some days ago it even happened in my project ONCE - and then not any more. >> But debugging is not easy because since that moment I changed many things, >> and basically the reason for my question is that I have no clear idea what >> EXACTLY should happen if I put a >> >> install(TARGETS mylibrary) >> >> into my CMakeLists.txt. Well, like you explained, and like what I also >> thought I had understood: nothing should happen during the configure and >> generate runs of cmake, and also not during the "ninja all" build run, but >> only during the "ninja install". or else cmake --build . --target install >> (which in turn calls ninja in my case). Indeed I observed that it does a >> build for "all" first if the initial project is not up to date. >> >> But then it tells me that it is successfully "installing" mylibrary, but >> I see no shared library appearing in the install tree! Or rather: it >> happened once, but not any more - and I should find out what is missing... > >Are building out-of-tree? (Are your source tree and build tree separate dir?) >If so, did you try removing the entire build tree and try again ? Yes, it's out of tree. And also I did this removal and rebuild! This is exactly how I realized my problem: I had done once an "install build" that copied library files to the target - and everything looked find from then on. Until I did that exercise - and realized that nothing is copied any more! And because I could not find any plausible reason why this library copying did not happen any more, I gave this "install" business up for the moment... >May be there is probably some mixup with your install DESTINATION in your >install command. The problem is that I did not even change anything in that part of the project from the moment when it "accidentally" happened once... But sure, it is never pure magic: I MUST have done something "wrong"! >> My current workaround is indeed that I am trying to avoid the install >> step altogether and build a crazy construction with configure_file stuff >> in order to get the libraries to the right place - and I know pretty >> well that this is NOT the way how things should be done properly. But I >> am afraid I will be ready with this workaround way faster than I will >> understand what is going on during this miraculous "install" process! > >Provide us with a stripped down non-working example and we may dig into it. >Otherwise it is very difficult to guess what is happening in your particular >case. That's exactly my problem: I am working on a ParaView custom project, and then trying to "derive" another one from the first! So there is nothing to be easily "stripped down" - it is simply a monster project - and I am almost sure if I am going to write a simple dummy project, everything will just work fine... And this is why I was asking for a more thorough documentation that what you can find at Kitware where not the processes are explained, but just "what to do". So from what I see, if you start a cmake project from scratch, you can start with simple concepts and add towards more complex ones, with growing understanding. However, if you start to build on ParaView, you start in the middle of an already highly complex project setup, with little documentation than just examples - and the entire process feels a bit like learning C++ with only the source code of a C++ compiler at hand: certainly possible, but takes a horrible amount of time... ;-) Side remark: Regarding cmake, this is also the reason why some days ago I was asking for certain improved functionalities for debug support, like a way to simply dump a list of "current targets" (including imported!), plus a way to dump also all valid "properties" of targets! Bottom line: Since such a documentation like I would like to find may not even exist, I think I should be happy that I have a "somehow working" solution for the moment! -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdk17 at ftml.net Mon Oct 7 11:54:55 2019 From: fdk17 at ftml.net (Fred Baksik) Date: Mon, 07 Oct 2019 11:54:55 -0400 Subject: [CMake] =?utf-8?q?Looking_for_an_explanation=3A_What_exactly_mea?= =?utf-8?q?ns_=22install=22_in_cmake_language=3F?= In-Reply-To: References: <718-5d9b5080-2f-67597200@248010465> Message-ID: <42383f68-1849-4668-a33c-fbe339a98f1e@www.fastmail.com> On Mon, Oct 7, 2019, at 11:25 AM, Eric Noulard wrote: > > > Le lun. 7 oct. 2019 ? 16:49, Cornelis Bockem?hl a ?crit : >> Thanks to both you and J Decker: I would say that this is still the part that I understood! So basically the word "install" in cmake language could be replaced by "copy" more or less in common human language - right? > > Nope I oversimplified. > This is not a bare copy, e.g. the runtime path (a.k.a. RPATH or RUNPATH) is updated as well. > File permissions are also set according to what was specified in install() via `PERMISSIONS which can be different from the file permissions of the file in the build directory.` `I think I saw that there was even a "make install/strip" feature that also stripped targets during installation.` `I think that the word install is used consistently between GNU autotools and CMake:` *2. * (Computer Science) to transfer (computer software) from a distribution file to a permanent location on disk, and prepare it for its particular environment and application. It's that "prepare it for..." clause that makes it different from a straight up copy. I don't know what may be causing your issues. I do know that at least one person felt that CMake installation is too aggressive in that it is always installing files that it doesn't need to during the installation step. https://stackoverflow.com/questions/58069372/does-cmake-always-evaluate-install-rules-even-for-up-to-date-targets#comment102540437_58069372 -- Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis at bockemuehl.ch Mon Oct 7 12:09:53 2019 From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=) Date: Mon, 07 Oct 2019 18:09:53 +0200 Subject: [CMake] =?utf-8?q?=3F=3D=3D=3Futf-8=3Fq=3F__Looking_for_an_expla?= =?utf-8?q?nation=3A_What_exactly_means_=22install=22_in_cmake_language=3F?= In-Reply-To: <42383f68-1849-4668-a33c-fbe339a98f1e@www.fastmail.com> Message-ID: <718-5d9b6380-39-67597200@248010509> > I think that the word install is used consistently between GNU autotools and CMake: Right, looks like it comes from the "good old times" when on Linux computers software was "installed" by downloading, then doing a "make" and a "make install" in order to get it running, while nowadays "installation" is normally done by a package manager that tries to resolve dependencies and works with binaries only. And CMake does some tricky things to do an "install" in order to later on "export" and "import" the code, or prepare it for "pack" etc. > It's that "prepare it for..." clause that makes it different from a straight up copy. In my case it looks like it "somehow works" for now without other preparations - but I hate this "solution" because it is against all "good cmake use" that would rather deal with targets and properties only, not with variables and directly copying files around, fiddling with shared library extensions (like so or dll) - but if working "the right way" takes so much time to figure out, it's finally a question of time economy that you finally end up with doing it "the hard way". (...which is of course the opposite of what a build tool should do for you: It should not make project setup more complicated, but more simple! But well - that's the real world ;-) ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at seefeld.name Mon Oct 7 12:47:31 2019 From: stefan at seefeld.name (stefan) Date: Mon, 7 Oct 2019 12:47:31 -0400 Subject: [CMake] HOWTO declare component inter-dependencies in multi-component packages In-Reply-To: References: <1570134227.3676.9.camel@kitware.com> <03301e84-711f-0d07-410a-d8d955e96ae7@seefeld.name> <1570135030.3676.10.camel@kitware.com> <1570136386.3676.11.camel@kitware.com> <1570137876.3676.12.camel@kitware.com> Message-ID: <3b398070-a5ab-815b-a16c-30099a2f7a13@seefeld.name> Hi, can you reproduce my observations ? I'm I doing something wrong or is there indeed an issue with CMake ? Should I follow up with a bug report ? Thanks, On 2019-10-04 2:20 p.m., stefan wrote: > > > On 2019-10-03 5:24 p.m., Kyle Edwards wrote: >> On Thu, 2019-10-03 at 17:08 -0400, stefan wrote: >>> Yes, that is exactly what I'm trying to do, but it doesn't seem to >>> have any effect. That is, `dpkg --info ...` doesn't list the >>> additional dependency, and correspondingly, running `apt-get install >>> ...` on the component package file will install the package without >>> first installing the prerequisite component. >>> Consider this declaration: >>> ? set(CPACK_COMPONENTS_ALL runtime development mstool) >>> If I now write >>> ? set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS runtime) >>> I will see no effect. That is, the "development" package still does >>> not depend on the "runtime" package. >>> So I try this: >>> ? set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS RUNTIME) >>> in case capitalization is required. Now the "runtime" component seems >>> to get packaged twice (as per the cmake logs), but still no correct >>> dependencies. >>> Is it time for a bug report ? >> Please send us a minimal CMakeLists.txt that reproduces the issue. > > Sure. Here it is. The relevant line part is line 5. Please let me know > what I'm doing wrong. > > Thanks, > > Stefan > -- > > ...ich hab' noch einen Koffer in Berlin... > Stefan -- ...ich hab' noch einen Koffer in Berlin... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 1478 bytes Desc: not available URL: From dmacq at instantiations.com Mon Oct 7 16:04:30 2019 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Mon, 7 Oct 2019 16:04:30 -0400 Subject: [CMake] LastTest log file name? Message-ID: <56d910da-1751-3e67-0945-6172807742ca@instantiations.com> Ctest creates a log file in ../build/Testing/Temporary with a name like LastTest_YYYYMMDD_HHMM. Is there a way I an add some descriptions to this name? For example, LastTest_YYYYMMDD_HHMM_MyTestDescription. Thanks in advance. -- Donald [|] A bad day in [] is better than a good day in {}. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From ryan.edward.mcclue at protonmail.com Mon Oct 7 23:04:36 2019 From: ryan.edward.mcclue at protonmail.com (Ryan Edward McClue) Date: Tue, 08 Oct 2019 03:04:36 +0000 Subject: [CMake] How to use custom linker, e.g. lld on windows Message-ID: To avoid repetition, please view: https://stackoverflow.com/questions/58253100/how-to-use-lld-with-cmake-on-windows Sent with [ProtonMail](https://protonmail.com) Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis at bockemuehl.ch Tue Oct 8 06:36:24 2019 From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=) Date: Tue, 08 Oct 2019 12:36:24 +0200 Subject: [CMake] =?utf-8?b?Pz09P3V0Zi04P3E/ID89PT91dGYtOD9xPyA/PSBMb29r?= =?utf-8?q?ing_for_an_explanation=3A_What_exactly_means_=22install=22_in_c?= =?utf-8?q?make_language?= In-Reply-To: Message-ID: <1450-5d9c6680-11-4c33c500@194394827> Dear all those wo answered on this thread: many thanks first of all! When I was starting this thread I was really a bit desperate - because things did not do what I expected, I felt like in the middle of a "cmake jungle" - and I doubted everything that I ever meant to have understood about cmake, mostly regarding that "install" and "export" business... The first thing I learned was thus one first certainty about the entire install process: "install" is indeed kind of "copy with a plus". Already very good to know to start with! Then there was the question if I could provide a strip down version of my project - and my problem was that "stripping down Paraview" is not so simple... However, I went back to one of my "teachers" - which is this web page -, and started to build a really extremely trivial example that includes the following points: - a first shared library "shlibbi" that has an exported header, uses an internal class and boost::regex - to have something "completely external". - a second shared library "shlibbu" that depends on "shlibbi" - and finally an "example" that depends on "shlibbu" And indeed - it works! At least in the sense that I can - build and "install" first "shlibbi" - then build and "install" "shlibbu", importing "shiibbi" with a find_package(shlibbi...) call - and finally build "example", importing "shlibbu" again with find_package(shlibbu...) and assuming that it would take care of "shlibbi" automatically And if I start now example, it does what it is supposed to do! At least if I do it inside the QtCreator that I am using as my development environment. And it does so even if the copy process that I would have expected did STILL not happen - like in my initial problem that was drving me mad. What I thought SHOULD happen is: if I "import" shlibbi into shlibbu, then "installing" shlibbu should also bring libshlibbi.so into the target library directory. And finally, if I "install" also the "example" main project, I would expect also both libshlibbi.so and libshlibbu.so in some location inside the install directory tree of "example". Instead, all the 3 binaries (shlibbi.so, shlibbu.so and example) remain in their "install" target trees. And "somehow" within QtCreator, the shared libraries are found if I start example. However, if I open a terminal in in the .../example/release/install/bin folder and type ./example there, it only complains about not finding libshlibbu.so. And if I manually copy libshlibbi.so and libshlibbu.so to that directory, I am STILL getting that same error message: it does not find the two libraries patchelf --set-rpath '$ORIGIN/.' example patchelf --set-rpath '$ORIGIN/.' libshlibbu.so Only if I added a RPATH to both example and libshlibbu.so, the start from the terminal also succeeded in the install target (bin) directory. So my initially very unspecific (and a bit desperate...) question is now much more precise: How can I get the *.so shared libraries into the same directory as the example (or else in a "parallel" lib64 library) - together with the correct RPATH settings? Because this I also learned from your answers: part of the "copy plus" is handling the RPATH properly! And this time I also have a stripped down example that does almost nothing (add 3 + 1) in a relatively complicated way (that even includes some regex pattern matching...) Thanks and regards, Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ExportExample.zip Type: application/zip Size: 293685 bytes Desc: not available URL: From cornelis at bockemuehl.ch Tue Oct 8 06:39:07 2019 From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=) Date: Tue, 08 Oct 2019 12:39:07 +0200 Subject: [CMake] =?utf-8?b?Pz09P3V0Zi04P3E/ID89PT91dGYtOD9xPyA/PSBMb29r?= =?utf-8?q?ing_for_an_explanation=3A_What_exactly_means_=22install=22__in_?= =?utf-8?q?cmake_language?= In-Reply-To: <1450-5d9c6680-11-4c33c500@194394827> Message-ID: <1450-5d9c6780-15-4c33c500@194394868> The missing link to my "cmake teacher web page": https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ Regards, Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis at bockemuehl.ch Tue Oct 8 06:51:01 2019 From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=) Date: Tue, 08 Oct 2019 12:51:01 +0200 Subject: [CMake] =?utf-8?b?Pz09P3V0Zi04P3E/ID89PT91dGYtOD9xPyA/PSBMb29r?= =?utf-8?q?ing_for_an_explanation=3A_What_exactly_means_=22install=22__in_?= =?utf-8?q?cmake_language?= In-Reply-To: <1450-5d9c6680-11-4c33c500@194394827> Message-ID: <1450-5d9c6a00-1b-4c33c500@194394871> One more finding: the "magic" that QtCreator does to start example also without any additional fiddling with the RPATH: it already contains a RUNPATH, and this points to the shared library libshlibbu.so in it's build tree location, not in the installed location - and the same with libshlibbu.so. And the "install" process indeed handles the RPATH/RUNPATH: it simply removes it! Meaning: it I want to end up what I initially expected, I have to do two additional things manually (or maybe there is an automatic way??): 1) copy the shared libraries to the "example" install directory tree 2) add some RPATH or RUNPATH setting to all the binaries that need it Regards, Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Tue Oct 8 07:10:43 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 8 Oct 2019 13:10:43 +0200 Subject: [CMake] ?= Looking for an explanation: What exactly means "install" in cmake language In-Reply-To: <1450-5d9c6a00-1b-4c33c500@194394871> References: <1450-5d9c6680-11-4c33c500@194394827> <1450-5d9c6a00-1b-4c33c500@194394871> Message-ID: Le mar. 8 oct. 2019 ? 12:52, Cornelis Bockem?hl a ?crit : > One more finding: the "magic" that QtCreator does to start example also > without any additional fiddling with the RPATH: it already contains a > RUNPATH, and this points to the shared library libshlibbu.so in it's build > tree location, not in the installed location - and the same with > libshlibbu.so. > > And the "install" process indeed handles the RPATH/RUNPATH: it simply > removes it! > > Meaning: it I want to end up what I initially expected, I have to do two > additional things manually (or maybe there is an automatic way??): > > 1) copy the shared libraries to the "example" install directory tree > 2) add some RPATH or RUNPATH setting to all the binaries that need it > You should read how RPATH handling is done with CMake. see: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling As you already noted there is a build RPATH and an install RPATH. The first is used when building the second replace the first after installation takes place. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.samoylov at gmail.com Tue Oct 8 07:58:42 2019 From: alexander.samoylov at gmail.com (Alexander) Date: Tue, 8 Oct 2019 13:58:42 +0200 Subject: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS In-Reply-To: References: Message-ID: Hi Craig, Thank you for this information. I never tried this way with the own CMakeLists.txt and I should try it. I found one efficient workaround however which is the option -DCMAKE_CXX_STANDARD_LIBRARIES=/DEF:additionalDefFile.def. It turned that the content of CMAKE_CXX_STANDARD_LIBRARIES is pushed to the linking command without any preprocessing which is exactly what I wanted (reference: https://cmake.cmake.narkive.com/UuC3PGkF/how-to-append-arbitrary-linker-options). What about stripping of the /DEF:option from CMAKE_SHARED_LINKER_FLAGS I see I would better ask CMake developers (cmake-developers at cmake.org) or submit a bug. -- Best Regards, Alexander On Sat, 5 Oct 2019 at 10:33, Craig Scott wrote: > > > On Sat, Oct 5, 2019 at 12:59 AM Alexander > wrote: > >> Dear Cristian, >> >> It would better for me not modifying CMakeFiles.txt, because as I wrote >> it is 3rd party stuff (we just download it and build, but some different >> way). >> My concern is why the command line option -DCMAKE_SHARED_LINKER_FLAGS >> deliberately ignores /DEF: option. It this behavior expected? What is the >> logic behind this behavior? Why not simply allow /DEF in >> CMAKE_SHARED_LINKER_FLAGS and not cut it? >> > > > You don't have to modify the third party CMakeLists.txt file to achieve > what Cristian suggested. You can call target_sources() on the third party > target from your own CMakeLists.txt file to add .def files to their > target. You don't have to be in the same directory scope as the target to > use target_sources() on it. > > I'm not familiar with why CMake is stripping out the /DEF: option in your > case, but I suspect it would be related to the way CMake expects to add > such options based on .def files given as sources. > > > >> On Fri, 4 Oct 2019 at 16:54, Cristian Adam >> wrote: >> >>> Hi, >>> >>> You should simply add the my_defs.def file as a source files to >>> add_library/add_executable. >>> CMake will automagically pass /DEF: to the linker with my_defs.def >>> >>> Cheers, >>> Cristian. >>> >>> On Fri, Oct 4, 2019 at 4:45 PM Alexander >>> wrote: >>> >>>> Hello, >>>> >>>> I would like to add an extra .defs file for linking of a DLL on >>>> Windows. I want to use the CMake command line option >>>> -DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the >>>> automatically generated >>>> /bin/.dir/Release/exports.def i see additionally >>>> /DEF:my_defs.defs in the resulting linking command, but it does not happen. >>>> >>>> What is especially irritating that CMake deliberately removes namely >>>> /DEF: from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I >>>> write /DEF111:my_defs.def for example) are accepted and I see them the >>>> linking command. >>>> >>>> I tried to reach the same goal using a CMakeLists.txt like this: >>>> >>>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def") >>>> >>>> but it did not help - the same way CMake removes my /DEF: option. >>>> >>>> Could you please open a ticket to fix this behavior to not cut /DEF: >>>> option from CMAKE_***_LINKER_FLAGS? >>>> >>>> On my opinion CMake should not interpret or modify the content of >>>> CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user >>>> specified it. If you have another opinion, please provide any other >>>> possibility to pass an arbitrary arguments to the linking command "as is" >>>> so that they are not modified. >>>> >>>> Any workaround is highly appreciated (better command-line, because we >>>> build 3rd party software and it would not really fine to change >>>> CMakeLists.txt) >>>> >>>> -- >>>> Best Regards, >>>> Alexander Samoilov >>>> Build & Integration Engineer >>>> Compart AG, 71034 B?blingen Germany >>>> >>> > > -- > 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 cornelis at bockemuehl.ch Tue Oct 8 08:07:35 2019 From: cornelis at bockemuehl.ch (cornelis) Date: Tue, 8 Oct 2019 14:07:35 +0200 Subject: [CMake] =?utf-8?q?=3F=3D_Looking_for_an_explanation=3A_What_exac?= =?utf-8?q?tly_means_=22install=22_in_cmake_language?= In-Reply-To: <1450-5d9c6a00-1b-4c33c500@194394871> References: <1450-5d9c6680-11-4c33c500@194394827> <1450-5d9c6a00-1b-4c33c500@194394871> Message-ID: <@localhost> Thanks for that hint! But for me the RPATH stuff is only a supplement, because in the context of a Paraview based project, most of my shared libs are plugins, and for these PV comes with its own mechanism to find them. But then all the more important is the question about actually copying the libs - to a specific location where the plugin finding procedure finds them! Regards, Cornelis > > On 08.10.2019 at 13:10, Eric Noulard wrote: > > > > > > > > Le mar. 8 oct. 2019 ? 12:52, Cornelis Bockem?hl a ?crit : > > > One more finding: the "magic" that QtCreator does to start example also without any additional fiddling with the RPATH: it already contains a RUNPATH, and this points to the shared library libshlibbu.so in it's build tree location, not in the installed location - and the same with libshlibbu.so. > > > > And the "install" process indeed handles the RPATH/RUNPATH: it simply removes it! > > > > Meaning: it I want to end up what I initially expected, I have to do two additional things manually (or maybe there is an automatic way??): > > > > 1) copy the shared libraries to the "example" install directory tree > > 2) add some RPATH or RUNPATH setting to all the binaries that need it > > > > You should read how RPATH handling is done with CMake. > > see: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling > > > > As you already noted there is a build RPATH and an install RPATH. > > The first is used when building the second replace the first after installation takes place. > > > > -- > > > > > > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sebastian.Setzer at de.bosch.com Tue Oct 8 09:08:50 2019 From: Sebastian.Setzer at de.bosch.com (Setzer Sebastian (CM-CI2/ECS2)) Date: Tue, 8 Oct 2019 13:08:50 +0000 Subject: [CMake] extending CMAKE__LINK_EXECUTABLE Message-ID: <72ee7e32a09546ef871198306fde7cc8@de.bosch.com> Dear list, I need to run a tool after building an executable, which will modify the executable itself. I intend to extend the toolchain for this, because it shall be done for every executable on this particular operating system. I think for this purpose, I need to change the rule CMAKE__LINK_EXECUTABLE. And I think I can't put multiple commands into that rule, so I need to write a wrapper which will be called instead of the normal linker, and the calls the normal linker and then that special tool. Right, so far? Now I'd like to pass a few additional parameters to this tool, which I'd like to get from a special target property. The rule currently looks like this: set(CMAKE_C_LINK_EXECUTABLE " -o ") And I wonder what these placeholders in angle brackets mean, and if there are more placeholders available. The manual doesn't say anything about this, unfortunately: https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_LINK_EXECUTABLE.html Is there, for example, a way to access arbitrary target properties? Or do I need to hide my special parameters somewhere in the LINK_OPTIONS property? Regards, Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis at bockemuehl.ch Tue Oct 8 09:21:09 2019 From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=) Date: Tue, 08 Oct 2019 15:21:09 +0200 Subject: [CMake] =?utf-8?b?Pz09P3V0Zi04P3E/ID89PT91dGYtOD9xPyA/PSBMb29r?= =?utf-8?q?ing_for_an_explanation=3A_What_exactly_means_=22install=22_in_c?= =?utf-8?q?make_language?= In-Reply-To: <@localhost> Message-ID: <1450-5d9c8d80-23-4c33c500@241013621> Actually I implemented yesterday a way how to copy the shared libs - with configure_file() and a lot of frickling around with the lib names myself, like finding out the extension on Linux and Windows, etc. Now I tried to include the following command in the "shlibbiConfig.cmake.in" file: install(TARGETS shlibbi::SHLIBbi ??? EXPORT ??????? shlibbi-targets ??? LIBRARY DESTINATION ??????? ${CMAKE_INSTALL_LIBDIR}) With this, I would expect that I am not "copying files", but "installing targets" - so actually a more abstract and powerful level - if it works! Since the generated shlibbiConfig.cmake would finally run in the context of the importing project, i.e. during a find_package() call, it should actually transfer the lib files from that imported target into the CMAKE_INSTALL_LIBDIR of the calling project - so exactly what I need. However, the result is an error message: ? install TARGETS given target "shlibbi::SHLIBbi" which does not exist. Well, it exists, because it is generated in the auto-generated shlibbiTargets.cmake file like this: add_library(shlibbi::SHLIBbi SHARED IMPORTED) and that shlibbiTargets.cmake was called inside shlibbiConfig.cmake BEFORE the above install(TARGETS...) call. Conclusion: "imported targets" are not "fully valid targets", because while I can now refer to that imported target, like with an #include ... in my source code, or with a successful link to the library, but obviously I cannot "install" that target. So my question can be even more specified now: Is there a way around this "install blockage" that would allow me to do the required transfer of the shared library into the lib folder of the calling project - and then even further also to the caller's calling project? I mean: with the effect of first moving libshlibbi.so to the lib directory of the shlibbu project, and then both the libshlibbi.so and the libshlibbu.so to the example project - of course including the required adaptation of the RPATH Because that is what I learned: doing the transfer with install() instead of a file copy through configure_file gives me not only the more abstract level of project organization, but also takes care of the RPATH... Best regards, Cornelis Am Dienstag, Oktober 08, 2019 14:07 CEST, cornelis schrieb: ?Thanks for that hint! But for me the RPATH stuff is only a supplement, because in?the context of a Paraview based project, most of my shared libs are plugins, and for these PV comes with its own mechanism to find them.?But then all the more important is the question about actually copying the libs - to a specific location where the plugin finding procedure finds them!?Regards, Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdk17 at ftml.net Tue Oct 8 09:48:39 2019 From: fdk17 at ftml.net (Fred Baksik) Date: Tue, 08 Oct 2019 09:48:39 -0400 Subject: [CMake] extending CMAKE__LINK_EXECUTABLE In-Reply-To: <72ee7e32a09546ef871198306fde7cc8@de.bosch.com> References: <72ee7e32a09546ef871198306fde7cc8@de.bosch.com> Message-ID: <78338321-7edc-423c-9c7a-a5312c8ef527@www.fastmail.com> On Tue, Oct 8, 2019, at 9:08 AM, Setzer Sebastian (CM-CI2/ECS2) via CMake wrote: > Dear list, > I need to run a tool after building an executable, which will modify the executable itself. > I intend to extend the toolchain for this, because it shall be done for every executable on this particular operating system. > > I think for this purpose, I need to change the rule CMAKE__LINK_EXECUTABLE. > And I think I can?t put multiple commands into that rule, so I need to write a wrapper which will be called instead of the normal linker, and the calls the normal linker and then that special tool. > > Right, so far? > > Now I?d like to pass a few additional parameters to this tool, which I?d like to get from a special target property. > > The rule currently looks like this: > set(CMAKE_C_LINK_EXECUTABLE " -o ") > > And I wonder what these placeholders in angle brackets mean, and if there are more placeholders available. The manual doesn?t say anything about this, unfortunately: > https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_LINK_EXECUTABLE.html > > Is there, for example, a way to access arbitrary target properties? > Or do I need to hide my special parameters somewhere in the LINK_OPTIONS property? > > Regards, > Sebastian > -- > I don't see how running arbitrary commands is possible in this way. If you want to avoid the boilerplate of adding a post-build custom command use a macro that performs the add_executable() and add_custom_command(). Then use the macro for each of the executable. Those markers aren't specified because it is part of implementation details of the Makefile (and Ninja?) generator and these items tend not to be documented for that reason (at least that is what I have come to understand from comments made on gitlab and developers mailing list). -- Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.c.dixon at durham.ac.uk Tue Oct 8 11:25:11 2019 From: mark.c.dixon at durham.ac.uk (DIXON, MARK C.) Date: Tue, 8 Oct 2019 15:25:11 +0000 Subject: [CMake] cmake end user vs. developer rpath handling Message-ID: Hi, I install lots of software packages under Linux and, increasingly, they use cmake instead of other methods (congratulations!) Frustratingly for me, I seem to keep ending up in a fight with the various developer's cmake config files over what rpath should be set, among other things. Obviously, I think I know best, so would like to know how to win please :) Sometimes, this does the trick. When it does, I'm very happy: cmake -D CMAKE_INSTALL_RPATH="/my/rpath" source_dir I'm currently looking at a package (https://github.com/PointCloudLibrary/pcl) where this has no bearing on the rpath of the installed software - I seem to get something set by the developer. Is there a way to reliably add to, or at least override, the developer's rpath in any cmake-built software? Thanks, Mark From cornelis at bockemuehl.ch Tue Oct 8 11:32:45 2019 From: cornelis at bockemuehl.ch (=?utf-8?q?Cornelis_Bockem=C3=BChl?=) Date: Tue, 08 Oct 2019 17:32:45 +0200 Subject: [CMake] =?utf-8?b?Pz09P3V0Zi04P3E/ID89PT91dGYtOD9xPyA/PSBMb29r?= =?utf-8?q?ing_for_an_explanation=3A_What_exactly_means_=22install=22_in_c?= =?utf-8?q?make_language?= In-Reply-To: <1450-5d9c8d80-23-4c33c500@241013621> Message-ID: <1450-5d9cac00-37-4c33c500@241013669> After stripping down the question to "can I install an imported target"? - with the purpose to copy the shared libraries also into the lib directory of the importing project - I could actually also use Google and look for an answer that somebody else might have been asked. And indeed: this seems to be a rather common question! And the "official answer" seems to be something like "this bug is a feature". It must have been a change request already years ago, and it was refused with different arguments, like: 1) proper RPATH handling is not possible in this case, because CMake cannot know the way how the shared library was built initially, so it is not able to manipulate it. At first this looks plausible, but then I was thinking that in Linux you always deal with ELF binaries, and there you have tools to manipulate RPATH/RUNPATH easily, and in Windows there is nothing similar - and others I don't know... 2) the target is already installed, so it makes no sense to install it again; it would only be a waste of disk space. Well, in my case it would make a lot of sense, and also for any kind of packager that might use the install directory it would be much easier if all the stuff is already in one location. 3...) maybe others - I did not follow further. In any case the conclusion is: It's like it is, and all my confusion came basically from this strange behaviour - that "install" is not always really "install" (but now I know at least when and why!). And the only way around - if I want to avoid the configure_file solution - would be to do some proper install(FILES...) instead - together with a little hacking regarding what the right files actually are. Best regards, Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From j-nagurne at ti.com Tue Oct 8 18:57:37 2019 From: j-nagurne at ti.com (Nagurne, James) Date: Tue, 8 Oct 2019 22:57:37 +0000 Subject: [CMake] CMake and Ninja, RERUN_CMAKE useless? Message-ID: <14e89973666b474385ec7b51396e1797@ti.com> Hi all, My question comes from a Ninja generator build system, and is specifically about an internal rule generated by cmake. What is the purpose of the RERUN_CMAKE rule generated by CMake with a Ninja generator? In the current repo, the only reference to this rule is in WriteTargetRebuildManifest here At line 1285, the rule is written out, seemingly as-is. According to lines 1274 to 1284, the only actual behavior of this command, which is executed whenever the source CMakeLists.txt file, files included from the CMakeLists, and some other CMake installation files change, is: cmake -S -B This seems completely insufficient for "re-running" cmake. The most obvious flaw is the absence of the generator. When I've seen this rule fire, my Ninja build system adds a useless Makefile to the build system, and then (hopefully) continues building as if nothing had been done at all, without so much as inspecting that Makefile. What about command-line arguments like -D? Am I missing the purpose of this rule or potentially doing something non-standard? The reason I send an email is because this behavior is sending my project into a cmake loop where it detects build.ninja is out of date, re-runs cmake to generate a Makefile instead of a ninja build system, and then infinitely repeats because it never actually re-ran anything. Thanks, JB Code Generation Texas Instruments -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jakub.Zakrzewski at scheer-group.com Wed Oct 9 02:09:19 2019 From: Jakub.Zakrzewski at scheer-group.com (Zakrzewski, Jakub) Date: Wed, 9 Oct 2019 06:09:19 +0000 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: References: Message-ID: <1570601359816.50976@scheer-group.com> ________________________________________ From: CMake on behalf of DIXON, MARK C. Sent: 08 October 2019 17:25 To: cmake at cmake.org Subject: [CMake] cmake end user vs. developer rpath handling >Sometimes, this does the trick. When it does, I'm very happy: > > cmake -D CMAKE_INSTALL_RPATH="/my/rpath" source_dir > >I'm currently looking at a package >(https://github.com/PointCloudLibrary/pcl) where this has no bearing on >the rpath of the installed software - I seem to get something set by the >developer. That "something" seems to be line 257: set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}") >Is there a way to reliably add to, or at least override, the developer's >rpath in any cmake-built software? Short of editing the build system scripts? I doubt... From ellonpaiva at gmail.com Wed Oct 9 03:51:19 2019 From: ellonpaiva at gmail.com (Ellon Paiva) Date: Wed, 9 Oct 2019 09:51:19 +0200 Subject: [CMake] Recover help text from option() ? Message-ID: <0af1fd88-6a92-65a2-4aca-826c0f80c900@gmail.com> Hi there, I was wondering if there was a way to recover the help text passed to an option to be used later below in the same CMake script. I saw that the help text goes into a comment before the option on the CMakeCache.txt, but is it stored in any recoverable variable during the script processing ? Best, Ellon From petr.kmoch at gmail.com Wed Oct 9 03:57:36 2019 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 9 Oct 2019 09:57:36 +0200 Subject: [CMake] Recover help text from option() ? In-Reply-To: <0af1fd88-6a92-65a2-4aca-826c0f80c900@gmail.com> References: <0af1fd88-6a92-65a2-4aca-826c0f80c900@gmail.com> Message-ID: Hi Ellon. On Wed, 9 Oct 2019 at 09:51, Ellon Paiva wrote: > Hi there, > > I was wondering if there was a way to recover the help text passed to an > option to be used later below in the same CMake script. > > I saw that the help text goes into a comment before the option on the > CMakeCache.txt, but is it stored in any recoverable variable during the > script processing ? > > Since option() just creates a cache variable, you should be able to retrieve that variable's HELPSTRING property ( https://cmake.org/cmake/help/latest/prop_cache/HELPSTRING.html ): option(SampleOpt "Help") get_property(result CACHE SampleOpt PROPERTY HELPSTRING) Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellonpaiva at gmail.com Wed Oct 9 05:11:01 2019 From: ellonpaiva at gmail.com (Ellon Paiva) Date: Wed, 9 Oct 2019 11:11:01 +0200 Subject: [CMake] Recover help text from option() ? In-Reply-To: References: <0af1fd88-6a92-65a2-4aca-826c0f80c900@gmail.com> Message-ID: Hi Petr, On Wed, Oct 9, 2019, 09:57 Petr Kmoch wrote: > Hi Ellon. > > On Wed, 9 Oct 2019 at 09:51, Ellon Paiva wrote: > >> Hi there, >> >> I was wondering if there was a way to recover the help text passed to an >> option to be used later below in the same CMake script. >> >> I saw that the help text goes into a comment before the option on the >> CMakeCache.txt, but is it stored in any recoverable variable during the >> script processing ? >> >> > Since option() just creates a cache variable, you should be able to > retrieve that variable's HELPSTRING property ( > https://cmake.org/cmake/help/latest/prop_cache/HELPSTRING.html ): > > option(SampleOpt "Help") > get_property(result CACHE SampleOpt PROPERTY HELPSTRING) > Awesome, thanks! Another somehow related question: is there a way to recover the name of all options defined in a project? Ellon > Petr > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Wed Oct 9 06:46:16 2019 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 9 Oct 2019 21:46:16 +1100 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: <1570601359816.50976@scheer-group.com> References: <1570601359816.50976@scheer-group.com> Message-ID: On Wed, Oct 9, 2019 at 5:24 PM Zakrzewski, Jakub < Jakub.Zakrzewski at scheer-group.com> wrote: > > ________________________________________ > From: CMake on behalf of DIXON, MARK C. < > mark.c.dixon at durham.ac.uk> > Sent: 08 October 2019 17:25 > To: cmake at cmake.org > Subject: [CMake] cmake end user vs. developer rpath handling > > >Sometimes, this does the trick. When it does, I'm very happy: > > > > cmake -D CMAKE_INSTALL_RPATH="/my/rpath" source_dir > > > >I'm currently looking at a package > >(https://github.com/PointCloudLibrary/pcl) where this has no bearing on > >the rpath of the installed software - I seem to get something set by the > >developer. > > That "something" seems to be line 257: > set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}") > > >Is there a way to reliably add to, or at least override, the developer's > >rpath in any cmake-built software? > > > Short of editing the build system scripts? I doubt... > The CMAKE_INSTALL_RPATH variable is used to initialise the INSTALL_RPATH property of a target when that target is created. If you are pulling in these other projects via add_subdirectory() rather than building them standalone, you could modify the INSTALL_RPATH property of the targets you want to change from within your own top level project after add_subdirectory() returns. -- 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 petr.kmoch at gmail.com Wed Oct 9 07:59:25 2019 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 9 Oct 2019 13:59:25 +0200 Subject: [CMake] Recover help text from option() ? In-Reply-To: References: <0af1fd88-6a92-65a2-4aca-826c0f80c900@gmail.com> Message-ID: On Wed, 9 Oct 2019 at 11:11, Ellon Paiva wrote: > Another somehow related question: is there a way to recover the name of > all options defined in a project? > > > You should be able to get this by reading the directory property CACHE_VARIABLES ( https://cmake.org/cmake/help/latest/prop_dir/CACHE_VARIABLES.html ) and going from there (querying variable types etc.), but note that it's "intended for debugging purposes." Please read the docs on cache variable properties ( https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-cache-entries ) to see what's possible. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Oct 9 08:16:02 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 9 Oct 2019 08:16:02 -0400 Subject: [CMake] CMake and Ninja, RERUN_CMAKE useless? In-Reply-To: <14e89973666b474385ec7b51396e1797@ti.com> References: <14e89973666b474385ec7b51396e1797@ti.com> Message-ID: The default generator and all other associated information ( '-D' ) is kept in the CMakeCache.txt file in the root of the build directory. The execution of `cmake -S -B ` will reload this cache before doing anything else. Have you verified that your build directory hasn't deleted this file? On Tue, Oct 8, 2019 at 8:31 PM Nagurne, James via CMake wrote: > > Hi all, > > > > My question comes from a Ninja generator build system, and is specifically about an internal rule generated by cmake. > > What is the purpose of the RERUN_CMAKE rule generated by CMake with a Ninja generator? > > > > In the current repo, the only reference to this rule is in WriteTargetRebuildManifest here > > At line 1285, the rule is written out, seemingly as-is. > > > > According to lines 1274 to 1284, the only actual behavior of this command, which is executed whenever the source CMakeLists.txt file, files included from the CMakeLists, and some other CMake installation files change, is: > > cmake -S -B > > > > This seems completely insufficient for ?re-running? cmake. The most obvious flaw is the absence of the generator. When I?ve seen this rule fire, my Ninja build system adds a useless Makefile to the build system, and then (hopefully) continues building as if nothing had been done at all, without so much as inspecting that Makefile. > > > > What about command-line arguments like -D? > > > > Am I missing the purpose of this rule or potentially doing something non-standard? The reason I send an email is because this behavior is sending my project into a cmake loop where it detects build.ninja is out of date, re-runs cmake to generate a Makefile instead of a ninja build system, and then infinitely repeats because it never actually re-ran anything. > > > > Thanks, > > JB > > Code Generation > > Texas Instruments > > -- > > 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 From ellonpaiva at gmail.com Wed Oct 9 08:17:32 2019 From: ellonpaiva at gmail.com (Ellon Paiva) Date: Wed, 9 Oct 2019 14:17:32 +0200 Subject: [CMake] Recover help text from option() ? In-Reply-To: References: <0af1fd88-6a92-65a2-4aca-826c0f80c900@gmail.com> Message-ID: <2b748ca6-5a9f-e154-f083-9ccbd3355f23@gmail.com> On 10/9/19 1:59 PM, Petr Kmoch wrote: > You should be able to get this by reading the directory property > CACHE_VARIABLES ( > https://cmake.org/cmake/help/latest/prop_dir/CACHE_VARIABLES.html ) > and going from there (querying variable types etc.), but note that > it's "intended for debugging purposes." Please read the docs on cache > variable properties ( > https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-cache-entries > ) to see what's possible. Perfect, thanks again ! Ellon From mark.c.dixon at durham.ac.uk Wed Oct 9 11:37:36 2019 From: mark.c.dixon at durham.ac.uk (DIXON, MARK C.) Date: Wed, 9 Oct 2019 15:37:36 +0000 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: <1570601359816.50976@scheer-group.com> References: <1570601359816.50976@scheer-group.com> Message-ID: On Wed, 9 Oct 2019, Zakrzewski, Jakub wrote: ... > That "something" seems to be line 257: set(CMAKE_INSTALL_RPATH > "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}") There's a second something that's adding boost's library directory. I'm guessing this is maybe coming from my copy of cmake's boost detection code. >> Is there a way to reliably add to, or at least override, the developer's >> rpath in any cmake-built software? > > Short of editing the build system scripts? I doubt... Drat. It would be a very useful feature to have: I install a lot of software for other people to use, and maintaining my own patches is a big headache. Big minus in the "comparison with GNU configure" column... setting LD_RUN_PATH normally does the trick there. Thanks, Mark From mark.c.dixon at durham.ac.uk Wed Oct 9 11:48:32 2019 From: mark.c.dixon at durham.ac.uk (DIXON, MARK C.) Date: Wed, 9 Oct 2019 15:48:32 +0000 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: References: <1570601359816.50976@scheer-group.com> Message-ID: On Wed, 9 Oct 2019, Craig Scott wrote: ... >>> Is there a way to reliably add to, or at least override, the developer's >>> rpath in any cmake-built software? >> >> Short of editing the build system scripts? I doubt... > > The CMAKE_INSTALL_RPATH variable is used to initialise the INSTALL_RPATH > property of a target when that target is created. If you are pulling in > these other projects via add_subdirectory() rather than building them > standalone, you could modify the INSTALL_RPATH property of the targets you > want to change from within your own top level project after > add_subdirectory() returns. ... Thanks for this. My knowledge of cmake is pretty poor - I assume it uses the same definition of target as make. So you're saying I'd need to know the project's interesting targets first. My choices are: maintain a patch to the software's build system files or maintain a patch to encaspulate the software's build system files and drive with a config file. Right? Thanks, Mark From robert.maynard at kitware.com Wed Oct 9 12:05:49 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 9 Oct 2019 12:05:49 -0400 Subject: [CMake] [EXTERNAL] Re: CMake and Ninja, RERUN_CMAKE useless? In-Reply-To: <80ee0ab5d0224405b36bb4a970b7a7ad@ti.com> References: <14e89973666b474385ec7b51396e1797@ti.com> <80ee0ab5d0224405b36bb4a970b7a7ad@ti.com> Message-ID: If you want to do a clean rebuild you can do the following: ninja clean or cmake --build --target clean ninja or cmake --build -j N On Wed, Oct 9, 2019 at 12:00 PM Nagurne, James wrote: > > That's the piece of the puzzle I was missing. Thank you! > > Yes, I had deleted the cache because I thought that would force a complete regeneration. I'm using a rather complicated system of ExternalProjects (LLVM), so I figured it was the quickest way to essentially force cmake to start from the beginning and reload those cache files without invalidating and forcing a rebuild of the executables and libraries I had already built > > Is there a way to do what I was looking for? I wouldn't be surprised if there wasn't, since removing those very fundamental building blocks might as well just be an rm -rf ./* > > JB > > -----Original Message----- > From: Robert Maynard [mailto:robert.maynard at kitware.com] > Sent: Wednesday, October 9, 2019 7:16 AM > To: Nagurne, James > Cc: cmake at cmake.org > Subject: [EXTERNAL] Re: [CMake] CMake and Ninja, RERUN_CMAKE useless? > > The default generator and all other associated information ( '-D' ) is > kept in the CMakeCache.txt file in the root of the build directory. > The execution of `cmake -S -B ` will reload > this cache before doing anything else. Have you verified that your > build directory hasn't deleted this file? > > On Tue, Oct 8, 2019 at 8:31 PM Nagurne, James via CMake wrote: > > > > Hi all, > > > > > > > > My question comes from a Ninja generator build system, and is specifically about an internal rule generated by cmake. > > > > What is the purpose of the RERUN_CMAKE rule generated by CMake with a Ninja generator? > > > > > > > > In the current repo, the only reference to this rule is in WriteTargetRebuildManifest here > > > > At line 1285, the rule is written out, seemingly as-is. > > > > > > > > According to lines 1274 to 1284, the only actual behavior of this command, which is executed whenever the source CMakeLists.txt file, files included from the CMakeLists, and some other CMake installation files change, is: > > > > cmake -S -B > > > > > > > > This seems completely insufficient for ?re-running? cmake. The most obvious flaw is the absence of the generator. When I?ve seen this rule fire, my Ninja build system adds a useless Makefile to the build system, and then (hopefully) continues building as if nothing had been done at all, without so much as inspecting that Makefile. > > > > > > > > What about command-line arguments like -D? > > > > > > > > Am I missing the purpose of this rule or potentially doing something non-standard? The reason I send an email is because this behavior is sending my project into a cmake loop where it detects build.ninja is out of date, re-runs cmake to generate a Makefile instead of a ninja build system, and then infinitely repeats because it never actually re-ran anything. > > > > > > > > Thanks, > > > > JB > > > > Code Generation > > > > Texas Instruments > > > > -- > > > > 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 From j-nagurne at ti.com Wed Oct 9 12:00:49 2019 From: j-nagurne at ti.com (Nagurne, James) Date: Wed, 9 Oct 2019 16:00:49 +0000 Subject: [CMake] [EXTERNAL] Re: CMake and Ninja, RERUN_CMAKE useless? In-Reply-To: References: <14e89973666b474385ec7b51396e1797@ti.com> Message-ID: <80ee0ab5d0224405b36bb4a970b7a7ad@ti.com> That's the piece of the puzzle I was missing. Thank you! Yes, I had deleted the cache because I thought that would force a complete regeneration. I'm using a rather complicated system of ExternalProjects (LLVM), so I figured it was the quickest way to essentially force cmake to start from the beginning and reload those cache files without invalidating and forcing a rebuild of the executables and libraries I had already built Is there a way to do what I was looking for? I wouldn't be surprised if there wasn't, since removing those very fundamental building blocks might as well just be an rm -rf ./* JB -----Original Message----- From: Robert Maynard [mailto:robert.maynard at kitware.com] Sent: Wednesday, October 9, 2019 7:16 AM To: Nagurne, James Cc: cmake at cmake.org Subject: [EXTERNAL] Re: [CMake] CMake and Ninja, RERUN_CMAKE useless? The default generator and all other associated information ( '-D' ) is kept in the CMakeCache.txt file in the root of the build directory. The execution of `cmake -S -B ` will reload this cache before doing anything else. Have you verified that your build directory hasn't deleted this file? On Tue, Oct 8, 2019 at 8:31 PM Nagurne, James via CMake wrote: > > Hi all, > > > > My question comes from a Ninja generator build system, and is specifically about an internal rule generated by cmake. > > What is the purpose of the RERUN_CMAKE rule generated by CMake with a Ninja generator? > > > > In the current repo, the only reference to this rule is in WriteTargetRebuildManifest here > > At line 1285, the rule is written out, seemingly as-is. > > > > According to lines 1274 to 1284, the only actual behavior of this command, which is executed whenever the source CMakeLists.txt file, files included from the CMakeLists, and some other CMake installation files change, is: > > cmake -S -B > > > > This seems completely insufficient for ?re-running? cmake. The most obvious flaw is the absence of the generator. When I?ve seen this rule fire, my Ninja build system adds a useless Makefile to the build system, and then (hopefully) continues building as if nothing had been done at all, without so much as inspecting that Makefile. > > > > What about command-line arguments like -D? > > > > Am I missing the purpose of this rule or potentially doing something non-standard? The reason I send an email is because this behavior is sending my project into a cmake loop where it detects build.ninja is out of date, re-runs cmake to generate a Makefile instead of a ninja build system, and then infinitely repeats because it never actually re-ran anything. > > > > Thanks, > > JB > > Code Generation > > Texas Instruments > > -- > > 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 From aaron at assonance.org Wed Oct 9 12:55:45 2019 From: aaron at assonance.org (Aaron Cohen) Date: Wed, 9 Oct 2019 12:55:45 -0400 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: References: <1570601359816.50976@scheer-group.com> Message-ID: Is it not feasible to just let the build system do whatever it is going to and use "chrpath" or "patchelf" to change the rpath after-the-fact? On Wed, Oct 9, 2019 at 11:48 AM DIXON, MARK C. wrote: > On Wed, 9 Oct 2019, Craig Scott wrote: > ... > >>> Is there a way to reliably add to, or at least override, the > developer's > >>> rpath in any cmake-built software? > >> > >> Short of editing the build system scripts? I doubt... > > > > The CMAKE_INSTALL_RPATH variable is used to initialise the INSTALL_RPATH > > property of a target when that target is created. If you are pulling in > > these other projects via add_subdirectory() rather than building them > > standalone, you could modify the INSTALL_RPATH property of the targets > you > > want to change from within your own top level project after > > add_subdirectory() returns. > ... > > Thanks for this. My knowledge of cmake is pretty poor - I assume it uses > the same definition of target as make. So you're saying I'd need to know > the project's interesting targets first. > > My choices are: maintain a patch to the software's build system files or > maintain a patch to encaspulate the software's build system files and > drive with a config file. Right? > > Thanks, > > Mark > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Wed Oct 9 15:36:21 2019 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 09 Oct 2019 21:36:21 +0200 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: <1570601359816.50976@scheer-group.com> References: <1570601359816.50976@scheer-group.com> Message-ID: <9C2AA509-2735-47F2-AABD-C41B25D0A1E4@hendrik-sattler.de> Am 9. Oktober 2019 08:09:19 MESZ schrieb "Zakrzewski, Jakub" >That "something" seems to be line 257: >set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}") IMHO setting this to something based on CMAKE_INSTALL_PREFIX is rarely a good idea if it can be relative to the runtime path of the executable. The above makes the program not relocatable even though that's easily possible on many systems. HS From nicke.claesson at gmail.com Wed Oct 9 16:03:19 2019 From: nicke.claesson at gmail.com (Niklas Claesson) Date: Wed, 9 Oct 2019 10:03:19 -1000 Subject: [CMake] Calling external build system Message-ID: Hello, I'm creating a static library (*.a) with a separate build system (cargo). That build system also produces a dependency file in the Makefile format (also produced by `gcc -M`). Is it possible to include this file into the generated makefiles either through a makefile inclusion or through cmake parsing the file? Obviously I don't want to call `cargo` unless one of my source files changed. Here is what I've got so far: ``` add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/rust/test/target/${RUST_PROFILE}/libtest.a COMMAND ${CMAKE_COMMAND} -E env SYSROOT=${CMAKE_SYSROOT} INCLUDES="${RUST_INCLUDES}" cargo build --manifest-path ${CMAKE_CURRENT_SOURCE_DIR}/rust/test/Cargo.toml --target-dir ${CMAKE_CURRENT_BINARY_DIR}/rust/test/target ${RUST_CARGO_FLAG} COMMAND ) add_custom_target(rust DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/rust/test/target/${RUST_PROFILE}/libbase.a) ``` Thanks - Niklas -------------- next part -------------- An HTML attachment was scrubbed... URL: From dustyn at blasig.us Wed Oct 9 16:23:48 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Wed, 9 Oct 2019 15:23:48 -0500 Subject: [CMake] Visual Studio Intellisense Integration Message-ID: Hi All, We are trying to clean up our Visual Studio flow with CMake. However, we are running into an issue with Intellisense not finding header files properly if we use target_include_directories(). For instance, given the simple example below, if we add the "global" include_directories() call Intellisense will work, but if we use target_include_directories() approach, Intellisense does not work. # Works if we use this ... include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include) add_library(foo ...) # Does not work using this ... target_include_directories(foo PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include) The build is fine, just Intellisense doesn't work. We noticed in the Visual Studio project file generated for the component the include directories show up as an AdditionalIncludeDirectories in a few sections like and but not under , for instance. I'm not sure where they should show up to affect Intellisense. In short, before we try a bunch of other stuff, I'd like to know in general what the status of integration with Intellisense should be so we know what to expect. Note, we are compiling a project with CUDA source, not sure if that makes a difference, but we are seeing the behavior even for non-CUDA targets. Thanks! Dustyn -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.gillman at ucl.ac.uk Thu Oct 10 04:16:17 2019 From: m.gillman at ucl.ac.uk (Gillman, Matthew) Date: Thu, 10 Oct 2019 08:16:17 +0000 Subject: [CMake] lintian errors when using cpack Message-ID: It's great that cpack can generate different packages - in my case, a .deb file for Debian. But if you then want to submit the generated .deb file to be part of Debian's official release, you have to run the lintian tool, and make sure you pass its checks. I have managed manually to fix some errors in the .deb file (which underneath is just an ar archive), and doubtless other warn ins and errors could be solved using appropriate CPACK_DEBIAN_* options in the CMakeLists.txt file. But I have a couple of errors which I don't know how to fix: E: libsopt3.0: shlib-missing-in-control-file libsopt 3.0 for usr/lib/libsopt.so.3.0.1 E: libsopt3.0: package-must-activate-ldconfig-trigger usr/lib/libsopt.so.3.0.1 Probably the shilbs file and control file need correcting, but I can't find anything which makes sense to me. Here is the shills file: libsopt 3 libsopt3.0 And here is the relevant section of the control file: Package: libsopt3.0 Priority: optional #Section: devel Section: libs #Version: 0.1.1 Version: 3.0 If anyone can help, I would be very grateful. Are there perhaps CPACK_DEBIAN_* options I could use to solve these issues? Thanks Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.c.dixon at durham.ac.uk Thu Oct 10 04:36:20 2019 From: mark.c.dixon at durham.ac.uk (DIXON, MARK C.) Date: Thu, 10 Oct 2019 08:36:20 +0000 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: References: <1570601359816.50976@scheer-group.com> Message-ID: On Wed, 9 Oct 2019, Aaron Cohen wrote: > Is it not feasible to just let the build system do whatever it is going to > and use "chrpath" or "patchelf" to change the rpath after-the-fact? Thanks for the suggestion, but I need to add directories to the rpath: I believe that neither utility allows it to increase in size. :) Mark From kerstin.s.keller at gmail.com Thu Oct 10 05:48:28 2019 From: kerstin.s.keller at gmail.com (Kerstin Keller) Date: Thu, 10 Oct 2019 11:48:28 +0200 Subject: [CMake] lintian errors when using cpack In-Reply-To: References: Message-ID: Hi, what CPACK_DEBIAN_* options have you set and to what values have you set them? I guess you're both using: set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON) set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS ON) When I generate the file for my lib it looks a bit different (e.g. it pins the package to a certain version, but not sure if it is required, and I have never run the linter on the package): libfoo 5 foo (= 5.4.0-1) Also, does CMake generate the `postinst` control file for you? That one should trigger the ldconfig execution, but maybe something is not correct there? How do other packages trigger the ldconfig execution? Best, Kerstin Am Do., 10. Okt. 2019 um 10:16 Uhr schrieb Gillman, Matthew < m.gillman at ucl.ac.uk>: > It's great that cpack can generate different packages - in my case, a .deb > file for Debian. > > But if you then want to submit the generated .deb file to be part of > Debian's official release, you have to run the lintian tool, and make sure > you pass its checks. I have managed manually to fix some errors in the .deb > file (which underneath is just an ar archive), and doubtless other warn ins > and errors could be solved using appropriate CPACK_DEBIAN_* options in the > CMakeLists.txt file. But I have a couple of errors which I don't know how > to fix: > > E: libsopt3.0: shlib-missing-in-control-file libsopt 3.0 for > usr/lib/libsopt.so.3.0.1 > E: libsopt3.0: package-must-activate-ldconfig-trigger > usr/lib/libsopt.so.3.0.1 > > Probably the shilbs file and control file need correcting, but I can't > find anything which makes sense to me. Here is the shills file: > > libsopt 3 libsopt3.0 > > And here is the relevant section of the control file: > > Package: libsopt3.0 > Priority: optional > #Section: devel > Section: libs > #Version: 0.1.1 > Version: 3.0 > > If anyone can help, I would be very grateful. Are there perhaps > CPACK_DEBIAN_* options I could use to solve these issues? > > Thanks > > > > Matthew > > > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.gillman at ucl.ac.uk Thu Oct 10 05:58:32 2019 From: m.gillman at ucl.ac.uk (Gillman, Matthew) Date: Thu, 10 Oct 2019 09:58:32 +0000 Subject: [CMake] lintian errors when using cpack In-Reply-To: References: Message-ID: Hi Kerstin Sorry, I forgot to list them. Right now I only have the following set: SET(CPACK_GENERATOR "DEB") SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me >") INCLUDE(CPack) I will try adding the two you suggest and see how it goes, but I wouldn?t be surprised if there were others I need too. I?ve had a look and I can?t see a file called `postint`. Thanks for your help Matthew From: CMake on behalf of Kerstin Keller Date: Thursday, 10 October 2019 at 10:49 To: "cmake at cmake.org" Subject: Re: [CMake] lintian errors when using cpack Hi, what CPACK_DEBIAN_* options have you set and to what values have you set them? I guess you're both using: set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON) set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS ON) When I generate the file for my lib it looks a bit different (e.g. it pins the package to a certain version, but not sure if it is required, and I have never run the linter on the package): libfoo 5 foo (= 5.4.0-1) Also, does CMake generate the `postinst` control file for you? That one should trigger the ldconfig execution, but maybe something is not correct there? How do other packages trigger the ldconfig execution? Best, Kerstin [Image removed by sender.] Am Do., 10. Okt. 2019 um 10:16 Uhr schrieb Gillman, Matthew >: It's great that cpack can generate different packages - in my case, a .deb file for Debian. But if you then want to submit the generated .deb file to be part of Debian's official release, you have to run the lintian tool, and make sure you pass its checks. I have managed manually to fix some errors in the .deb file (which underneath is just an ar archive), and doubtless other warn ins and errors could be solved using appropriate CPACK_DEBIAN_* options in the CMakeLists.txt file. But I have a couple of errors which I don't know how to fix: E: libsopt3.0: shlib-missing-in-control-file libsopt 3.0 for usr/lib/libsopt.so.3.0.1 E: libsopt3.0: package-must-activate-ldconfig-trigger usr/lib/libsopt.so.3.0.1 Probably the shilbs file and control file need correcting, but I can't find anything which makes sense to me. Here is the shills file: libsopt 3 libsopt3.0 And here is the relevant section of the control file: Package: libsopt3.0 Priority: optional #Section: devel Section: libs #Version: 0.1.1 Version: 3.0 If anyone can help, I would be very grateful. Are there perhaps CPACK_DEBIAN_* options I could use to solve these issues? Thanks Matthew -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Thu Oct 10 06:05:38 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 10 Oct 2019 12:05:38 +0200 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: References: <1570601359816.50976@scheer-group.com> Message-ID: Le jeu. 10 oct. 2019 ? 10:36, DIXON, MARK C. a ?crit : > On Wed, 9 Oct 2019, Aaron Cohen wrote: > > > Is it not feasible to just let the build system do whatever it is going > to > > and use "chrpath" or "patchelf" to change the rpath after-the-fact? > > Thanks for the suggestion, but I need to add directories to the rpath: I > believe that neither utility allows it to increase in size. > No they can't because the maximum size is burried into the binary ELF file, that why CMake "reserve" some space with many ";;;" in order to replace BUILD_RPATH with INSTALL_RPATH when doing 'install'. Note however that you should be able to "delete" RPATH: chrpath -d and then rely on LD_LIBRARY_PATH, ld.so.config, etc.... The thing I don't quite understand why you need to replace/amend RPATH. In my (very personal) use case when I have to integrate third-party software: 1a) I compile them from source and install them using the install prefix *I need*. For cmake enabled build the RPATH will be updated with the one I need *during install* 2a) I use relocatable binary package (of any kind rpm, deb, or even tar.gz) for which I know that RPATH are relative which can adapt to the location where I put them. If I cannot find a relocatable binary package then I go back to 1a). As noted by Hendrik not every software developer are aware of the need for relocation so they may bury non-relocatable rpath in their buildsystem. Note that there is usually 2 options for CMake buildsystem and install RPATH. You can either: 1. set some install RPATH (preferably in a relocatable way using $ORIGIN) 2. don't specify install RPATH at all and let the final user/integrator setup LD_LIBRARY_PATH or ld.so.config etc... This is quite well summarized here: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling If the developers of the software you are using have chosen in their CMake build-system to define an install RPATH your only safe bet is probably to build & install the software at your favorite location or propose an upstream patch for supporting unspecified RPATH. But may be I miss something in your use case? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Thu Oct 10 06:35:10 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 10 Oct 2019 12:35:10 +0200 Subject: [CMake] lintian errors when using cpack In-Reply-To: References: Message-ID: Le jeu. 10 oct. 2019 ? 11:58, Gillman, Matthew a ?crit : > Hi Kerstin > > > > Sorry, I forgot to list them. Right now I only have the following set: > > > > SET(CPACK_GENERATOR "DEB") > > SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me ") > > INCLUDE(CPack) > > > > I will try adding the two you suggest and see how it goes, but I wouldn?t > be surprised if there were others I need too. > You may review CPack Deb feature in the documentation as well: https://cmake.org/cmake/help/v3.15/cpack_gen/deb.html I?ve had a look and I can?t see a file called `postint`. > > > > Thanks for your help > > > > Matthew > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.gillman at ucl.ac.uk Thu Oct 10 06:58:57 2019 From: m.gillman at ucl.ac.uk (Gillman, Matthew) Date: Thu, 10 Oct 2019 10:58:57 +0000 Subject: [CMake] lintian errors when using cpack In-Reply-To: References: Message-ID: Hi again I just tried adding those additional two options, but I am getting the same error with lintian. Is there something wrong in my shlibs or control file? Thanks Matthew From: CMake on behalf of "Gillman, Matthew" Date: Thursday, 10 October 2019 at 10:58 To: Kerstin Keller , "cmake at cmake.org" Subject: Re: [CMake] lintian errors when using cpack Hi Kerstin Sorry, I forgot to list them. Right now I only have the following set: SET(CPACK_GENERATOR "DEB") SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me >") INCLUDE(CPack) I will try adding the two you suggest and see how it goes, but I wouldn?t be surprised if there were others I need too. I?ve had a look and I can?t see a file called `postint`. Thanks for your help Matthew From: CMake on behalf of Kerstin Keller Date: Thursday, 10 October 2019 at 10:49 To: "cmake at cmake.org" Subject: Re: [CMake] lintian errors when using cpack Hi, what CPACK_DEBIAN_* options have you set and to what values have you set them? I guess you're both using: set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON) set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS ON) When I generate the file for my lib it looks a bit different (e.g. it pins the package to a certain version, but not sure if it is required, and I have never run the linter on the package): libfoo 5 foo (= 5.4.0-1) Also, does CMake generate the `postinst` control file for you? That one should trigger the ldconfig execution, but maybe something is not correct there? How do other packages trigger the ldconfig execution? Best, Kerstin [Image removed by sender.] Am Do., 10. Okt. 2019 um 10:16 Uhr schrieb Gillman, Matthew >: It's great that cpack can generate different packages - in my case, a .deb file for Debian. But if you then want to submit the generated .deb file to be part of Debian's official release, you have to run the lintian tool, and make sure you pass its checks. I have managed manually to fix some errors in the .deb file (which underneath is just an ar archive), and doubtless other warn ins and errors could be solved using appropriate CPACK_DEBIAN_* options in the CMakeLists.txt file. But I have a couple of errors which I don't know how to fix: E: libsopt3.0: shlib-missing-in-control-file libsopt 3.0 for usr/lib/libsopt.so.3.0.1 E: libsopt3.0: package-must-activate-ldconfig-trigger usr/lib/libsopt.so.3.0.1 Probably the shilbs file and control file need correcting, but I can't find anything which makes sense to me. Here is the shills file: libsopt 3 libsopt3.0 And here is the relevant section of the control file: Package: libsopt3.0 Priority: optional #Section: devel Section: libs #Version: 0.1.1 Version: 3.0 If anyone can help, I would be very grateful. Are there perhaps CPACK_DEBIAN_* options I could use to solve these issues? Thanks Matthew -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.c.dixon at durham.ac.uk Thu Oct 10 07:08:16 2019 From: mark.c.dixon at durham.ac.uk (DIXON, MARK C.) Date: Thu, 10 Oct 2019 11:08:16 +0000 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: References: <1570601359816.50976@scheer-group.com> Message-ID: On Thu, 10 Oct 2019, Eric Noulard wrote: ... > No they can't because the maximum size is burried into the binary ELF file, > that why CMake "reserve" some space with many ";;;" in order to replace > BUILD_RPATH with INSTALL_RPATH when doing > 'install'. Hi Eric, Interesting - any ideas on how big the padding is? > Note however that you should be able to "delete" RPATH: chrpath -d > and then rely on LD_LIBRARY_PATH, ld.so.config, etc.... > > The thing I don't quite understand why you need to replace/amend RPATH. In > my (very personal) use case when I have to integrate third-party software: My use case is where: - I install some software, made available to others via environment modules (http://modules.sourceforge.net/). - The installed software is dynamically linked to other libraries, also installed via environment modules. - I don't want to make people load modules for prerequisite libraries (and prerequisites for the prerequisites...) to use the software. A complication is that I end up having to build lots of copies of the same software but built with different prerequisites... so it has to be automated on top of the upstream project's build system. For applications using libraries, I've tended to use wrapper scripts as it means fewer arguments with build systems. But for libraries using libraries, rpath's the only real option. My rpath can get quite long. ... > If the developers of the software you are using have chosen in their CMake > build-system to define an install RPATH your only safe bet > is probably to build & install the software at your favorite location or > propose an upstream patch for supporting unspecified RPATH. > > But may be I miss something in your use case? I guess I should be proposing upstream patches but, there are so many software projects to do this for, it has always been simpler to carry forward a small patch or patches. Perhaps I should be a better citizen. In this case, what feels easiest is to keep a patch commenting out the developer's RPATH definition in CMakeLists.txt, identified by Jakub earlier. Cheers, Mark From eric.noulard at gmail.com Thu Oct 10 07:48:46 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 10 Oct 2019 13:48:46 +0200 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: References: <1570601359816.50976@scheer-group.com> Message-ID: Le jeu. 10 oct. 2019 ? 13:08, DIXON, MARK C. a ?crit : > On Thu, 10 Oct 2019, Eric Noulard wrote: > ... > > No they can't because the maximum size is burried into the binary ELF > file, > > that why CMake "reserve" some space with many ";;;" in order to replace > > BUILD_RPATH with INSTALL_RPATH when doing > > 'install'. > > Hi Eric, > > Interesting - any ideas on how big the padding is? > Not sure, but I bet CMake is reserving as much space as needed for the forthcoming INSTALL_RPATH (as opposed to BUILD_RPATH) he knows when specified in the CMakeLists.txt I you rebuild the concerned from source try configuring it with a stupidly long CMAKE_INSTALL_RPATH i.e. cmake -DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath .... Then, you can surely have a look using chrpath -l lib_or_exe. > > Note however that you should be able to "delete" RPATH: chrpath -d > > and then rely on LD_LIBRARY_PATH, ld.so.config, etc.... > > > > The thing I don't quite understand why you need to replace/amend RPATH. > In > > my (very personal) use case when I have to integrate third-party > software: > > My use case is where: > > - I install some software, made available to others via environment > modules (http://modules.sourceforge.net/). > > - The installed software is dynamically linked to other libraries, also > installed via environment modules. > > - I don't want to make people load modules for prerequisite libraries > (and prerequisites for the prerequisites...) to use the software. > ok I see, I did use modules a long time ago on some now oldish supercomputer in order to play with various compilers of library versions. > > A complication is that I end up having to build lots of copies of the same > software but built with different prerequisites... so it has to be > automated on top of the upstream project's build system. > > For applications using libraries, I've tended to use wrapper scripts as it > means fewer arguments with build systems. But for libraries using > libraries, rpath's the only real option. > No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case? Removing rpath is easy; chrpath -d lib_or_exe > My rpath can get quite long. > Yes now I see why, depending on the number of prerequisite you have and how many modules are loaded. > ... > > If the developers of the software you are using have chosen in their > CMake > > build-system to define an install RPATH your only safe bet > > is probably to build & install the software at your favorite location or > > propose an upstream patch for supporting unspecified RPATH. > > > > But may be I miss something in your use case? > > I guess I should be proposing upstream patches but, there are so many > software projects to do this for, it has always been simpler to carry > forward a small patch or patches. Perhaps I should be a better citizen. > It may not be tractable to file dozen of upstream patch and wait for feedback but in the case the build system does not offer a way to chose install rpath content I think you are stucked (beside remove rpath). In this case, what feels easiest is to keep a patch commenting out the > developer's RPATH definition in CMakeLists.txt, identified by Jakub > earlier. > Yes I agree. However I my hypothesis of space reservation in RPATH by cmake is write you may want to replace with something that fits your needs and not simply commenting it out. Or may be commenting it out and specify CMAKE_INSTALL_RPATH on the command line: cmake -DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath .... https://cmake.org/cmake/help/v3.15/variable/CMAKE_INSTALL_RPATH.html -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jakub.Zakrzewski at scheer-group.com Thu Oct 10 08:00:23 2019 From: Jakub.Zakrzewski at scheer-group.com (Zakrzewski, Jakub) Date: Thu, 10 Oct 2019 12:00:23 +0000 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: <1570708747208.32811@scheer-group.com> References: <1570601359816.50976@scheer-group.com> , , <1570708747208.32811@scheer-group.com> Message-ID: <1570708823051.956@scheer-group.com> ________________________________ From: CMake on behalf of Eric Noulard Sent: 10 October 2019 12:05 To: DIXON, MARK C. Cc: cmake at cmake.org Subject: [DKIM] Re: [CMake] cm?ake end user vs. developer rpath handling > No they can't because the maximum size is burried into the binary ELF file, > that why CMake "reserve" some space with many ";;;" in order to replace BUILD_RPATH with INSTALL_RPATH when doing > 'install'. Interesting. So you're saying that this: https://github.com/NixOS/patchelf/blob/8cc2d64444b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319? does not really work? (An honest question) -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Thu Oct 10 08:30:32 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 10 Oct 2019 14:30:32 +0200 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: <1570708823051.956@scheer-group.com> References: <1570601359816.50976@scheer-group.com> <1570708747208.32811@scheer-group.com> <1570708823051.956@scheer-group.com> Message-ID: Le jeu. 10 oct. 2019 ? 14:02, Zakrzewski, Jakub < Jakub.Zakrzewski at scheer-group.com> a ?crit : > ------------------------------ > *From:* CMake on behalf of Eric Noulard < > eric.noulard at gmail.com> > *Sent:* 10 October 2019 12:05 > *To:* DIXON, MARK C. > *Cc:* cmake at cmake.org > *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling > > > > No they can't because the maximum size is burried into the binary ELF > file, > > that why CMake "reserve" some space with many ";;;" in order to replace > BUILD_RPATH with INSTALL_RPATH when doing > > 'install'. > > Interesting. > So you're saying that this: > https://github.com/NixOS/patchelf/blob/8cc2d64444b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319 > does not really work? (An honest question) > Nope I meant that my manual page forr chrpath says: -r | --replace Replace current rpath or runpath setting with the path given. The new path must be shorter or the same length as the current path. patchelf does not seem to have this limitation. I remember trying and being hit by that issue, but I did not tried it recently. I'll try again and come back to you. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Thu Oct 10 08:43:55 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 10 Oct 2019 14:43:55 +0200 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: References: <1570601359816.50976@scheer-group.com> <1570708747208.32811@scheer-group.com> <1570708823051.956@scheer-group.com> Message-ID: Le jeu. 10 oct. 2019 ? 14:30, Eric Noulard a ?crit : > > > Le jeu. 10 oct. 2019 ? 14:02, Zakrzewski, Jakub < > Jakub.Zakrzewski at scheer-group.com> a ?crit : > >> ------------------------------ >> *From:* CMake on behalf of Eric Noulard < >> eric.noulard at gmail.com> >> *Sent:* 10 October 2019 12:05 >> *To:* DIXON, MARK C. >> *Cc:* cmake at cmake.org >> *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling >> >> >> > No they can't because the maximum size is burried into the binary ELF >> file, >> > that why CMake "reserve" some space with many ";;;" in order to replace >> BUILD_RPATH with INSTALL_RPATH when doing >> > 'install'. >> >> Interesting. >> So you're saying that this: >> https://github.com/NixOS/patchelf/blob/8cc2d64444b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319 >> does not really work? (An honest question) >> > > Nope I meant that my manual page forr chrpath says: > -r | --replace > Replace current rpath or runpath setting with the path > given. The new path must be shorter or the same length as the current path. > > patchelf does not seem to have this limitation. > I remember trying and being hit by that issue, but I did not tried it > recently. > I'll try again and come back to you. > with chrpath try to replace an rpath with a longer one I get: new rpath '/../lib:/purposely/too/long/rpath/hdsjds/dshkjhdsk/dsgdjsj' too large; maximum length 104 with patchelf is works with an intriguing warning: warning: working around a Linux kernel bug by creating a hole of 2093056 bytes in ?/path/to/executable? which seems to be a resolved issue: https://github.com/NixOS/patchelf/issues/92 after that on the modified executable, chrpath is printing weird output when asking to read rpath. patchelf does properly print modified rpath. I think the SO article gives enough reference for this: https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary So I was wrong, thank you for your honest question Jakub. I learned something usefull thanks to you. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jakub.Zakrzewski at scheer-group.com Thu Oct 10 09:09:32 2019 From: Jakub.Zakrzewski at scheer-group.com (Zakrzewski, Jakub) Date: Thu, 10 Oct 2019 13:09:32 +0000 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: References: <1570601359816.50976@scheer-group.com> <1570708747208.32811@scheer-group.com> <1570708823051.956@scheer-group.com> , Message-ID: <1570712966464.40473@scheer-group.com> ________________________________ From: Eric Noulard Sent: 10 October 2019 14:43 To: Zakrzewski, Jakub Cc: cmake at cmake.org Subject: Re: [CMake] cmake end user vs. developer rpath handling > So I was wrong, thank you for your honest question Jakub. > I learned something usefull thanks to you. ?No problem, thanks for trying out. I'd like to think that asking and answering questions (even the seemingly stupid ones) makes us learn new things. -- Have a nice one, Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at seefeld.name Thu Oct 10 09:25:57 2019 From: stefan at seefeld.name (stefan) Date: Thu, 10 Oct 2019 09:25:57 -0400 Subject: [CMake] HOWTO declare component inter-dependencies in multi-component packages In-Reply-To: <3b398070-a5ab-815b-a16c-30099a2f7a13@seefeld.name> References: <1570134227.3676.9.camel@kitware.com> <03301e84-711f-0d07-410a-d8d955e96ae7@seefeld.name> <1570135030.3676.10.camel@kitware.com> <1570136386.3676.11.camel@kitware.com> <1570137876.3676.12.camel@kitware.com> <3b398070-a5ab-815b-a16c-30099a2f7a13@seefeld.name> Message-ID: <9c694378-b19b-0ae0-b05e-408346636546@seefeld.name> ping ? On 2019-10-07 12:47 p.m., stefan wrote: > > Hi, > > can you reproduce my observations ? I'm I doing something wrong or is > there indeed an issue with CMake ? Should I follow up with a bug report ? > > Thanks, > > On 2019-10-04 2:20 p.m., stefan wrote: >> >> >> On 2019-10-03 5:24 p.m., Kyle Edwards wrote: >>> On Thu, 2019-10-03 at 17:08 -0400, stefan wrote: >>>> Yes, that is exactly what I'm trying to do, but it doesn't seem to >>>> have any effect. That is, `dpkg --info ...` doesn't list the >>>> additional dependency, and correspondingly, running `apt-get install >>>> ...` on the component package file will install the package without >>>> first installing the prerequisite component. >>>> Consider this declaration: >>>> ? set(CPACK_COMPONENTS_ALL runtime development mstool) >>>> If I now write >>>> ? set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS runtime) >>>> I will see no effect. That is, the "development" package still does >>>> not depend on the "runtime" package. >>>> So I try this: >>>> ? set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS RUNTIME) >>>> in case capitalization is required. Now the "runtime" component seems >>>> to get packaged twice (as per the cmake logs), but still no correct >>>> dependencies. >>>> Is it time for a bug report ? >>> Please send us a minimal CMakeLists.txt that reproduces the issue. >> >> Sure. Here it is. The relevant line part is line 5. Please let me >> know what I'm doing wrong. >> >> Thanks, >> >> Stefan >> -- >> >> ...ich hab' noch einen Koffer in Berlin... >> > > Stefan > -- > > ...ich hab' noch einen Koffer in Berlin... > Stefan -- ...ich hab' noch einen Koffer in Berlin... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 1478 bytes Desc: not available URL: From mark.c.dixon at durham.ac.uk Thu Oct 10 10:01:29 2019 From: mark.c.dixon at durham.ac.uk (DIXON, MARK C.) Date: Thu, 10 Oct 2019 14:01:29 +0000 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: References: <1570601359816.50976@scheer-group.com> Message-ID: On Thu, 10 Oct 2019, Eric Noulard wrote: ... > No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case? > Removing rpath is easy; chrpath -d lib_or_exe You could but, to avoid a maintenance headache, you'd normally end up getting the environment module to load any prereq environment modules, which would modify LD_LIBRARY_PATH. In either case, it'd mean unexpectedly polluting the user's environment with things they didn't explicitly ask for, which I don't like doing. ... > Or may be commenting it out and specify CMAKE_INSTALL_RPATH on the command > line: > > cmake > -DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath > .... ... Sorry - yes, I'm commenting it out and then specifying the CMAKE_INSTALL_RPATH I want on the command line. Best, Mark From mark.c.dixon at durham.ac.uk Thu Oct 10 10:03:51 2019 From: mark.c.dixon at durham.ac.uk (DIXON, MARK C.) Date: Thu, 10 Oct 2019 14:03:51 +0000 Subject: [CMake] cmake end user vs. developer rpath handling In-Reply-To: References: <1570601359816.50976@scheer-group.com> <1570708747208.32811@scheer-group.com> <1570708823051.956@scheer-group.com> Message-ID: On Thu, 10 Oct 2019, Eric Noulard wrote: ... > with patchelf is works with an intriguing warning: > warning: working around a Linux kernel bug by creating a hole of 2093056 > bytes in ?/path/to/executable? > > which seems to be a resolved issue: > https://github.com/NixOS/patchelf/issues/92 > > after that on the modified executable, > chrpath is printing weird output when asking to read rpath. > patchelf does properly print modified rpath. > > I think the SO article gives enough reference for this: > https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary > > So I was wrong, thank you for your honest question Jakub. > I learned something usefull thanks to you. ... Thanks both! Great news - being unable to grow rpath was always really irritating. Mark From robert.maynard at kitware.com Thu Oct 10 14:57:53 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 10 Oct 2019 14:57:53 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing Message-ID: I am proud to announce the first CMake 3.16 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.16 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.16/release/3.16.html Some of the more significant changes in CMake 3.16 are: * CMake learned to support the Objective C ("OBJC") and Objective C++ ("OBJCXX") languages. They may be enabled via the "project()" and "enable_language()" commands. When "OBJC" or "OBJCXX" is enabled, source files with the ".m" or ".mm", respectively, will be compiled as Objective C or C++. Otherwise they will be treated as plain C++ sources as they were before. * The "target_precompile_headers()" command was added to specify a list of headers to precompile for faster compilation times. * The "UNITY_BUILD" target property was added to tell generators to batch include source files for faster compilation times. * The "find_file()", "find_library()", "find_path()", "find_package()", and "find_program()" commands have learned to check the following variables to control searching * "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching the cmake-specific environment variables. * "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake- specific cache variables. * "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching cmake platform specific variables. * "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of "_ROOT" variables. * "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the searching the standard system environment variables. * The "file()" command learned a new sub-command, "GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the list of libraries linked by an executable or library. This sub- command is intended as a replacement for "GetPrerequisites". * "ctest(1)" now has the ability to serialize tests based on hardware requirements for each test. See Hardware Allocation for details. * On AIX, executables using the "ENABLE_EXPORTS" target property now produce a linker import file with a ".imp" extension in addition to the executable file. Plugins (created via "add_library()" with the "MODULE" option) that use "target_link_libraries()" to link to the executable for its symbols are now linked using the import file. The "install(TARGETS)" command now installs the import file as an "ARCHIVE" artifact. * On AIX, runtime linking is no longer enabled by default. CMake provides the linker enough information to resolve all symbols up front. One may manually enable runtime linking for shared libraries and/or loadable modules by adding "-Wl,-G" to their link flags (e.g. in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS" variable). One may manually enable runtime linking for executables by adding "-Wl,-brtl" to their link flags (e.g. in the "CMAKE_EXE_LINKER_FLAGS" variable). * "cmake(1)" "-E" now supports "true" and "false" commands, which do nothing while returning exit codes of 0 and 1, respectively. * "cmake(1)" gained a "--trace-redirect=" command line option that can be used to redirect "--trace" output to a file instead of "stderr". * The "cmake(1)" "--loglevel" command line option has been renamed to "--log-level" to make it consistent with the naming of other command line options. The "--loglevel" option is still supported to preserve backward compatibility. * The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been deprecated. Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable instead. * The "GetPrerequisites" module has been deprecated, as it has been superceded by "file(GET_RUNTIME_DEPENDENCIES)". CMake 3.16 Release Notes ************************ Changes made since CMake 3.15 include the following. New Features ============ Languages --------- * CMake learned to support the Objective C ("OBJC") and Objective C++ ("OBJCXX") languages. They may be enabled via the "project()" and "enable_language()" commands. When "OBJC" or "OBJCXX" is enabled, source files with the ".m" or ".mm", respectively, will be compiled as Objective C or C++. Otherwise they will be treated as plain C++ sources as they were before. Compilers --------- * The "Clang" compiler is now supported on "Solaris". Platforms --------- * On AIX, executables using the "ENABLE_EXPORTS" target property now produce a linker import file with a ".imp" extension in addition to the executable file. Plugins (created via "add_library()" with the "MODULE" option) that use "target_link_libraries()" to link to the executable for its symbols are now linked using the import file. The "install(TARGETS)" command now installs the import file as an "ARCHIVE" artifact. * On AIX, runtime linking is no longer enabled by default. CMake provides the linker enough information to resolve all symbols up front. One may manually enable runtime linking for shared libraries and/or loadable modules by adding "-Wl,-G" to their link flags (e.g. in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS" variable). One may manually enable runtime linking for executables by adding "-Wl,-brtl" to their link flags (e.g. in the "CMAKE_EXE_LINKER_FLAGS" variable). Command-Line ------------ * "cmake(1)" "-E" now supports "true" and "false" commands, which do nothing while returning exit codes of 0 and 1, respectively. * "cmake(1)" gained a "--trace-redirect=" command line option that can be used to redirect "--trace" output to a file instead of "stderr". * The "cmake(1)" "--loglevel" command line option has been renamed to "--log-level" to make it consistent with the naming of other command line options. The "--loglevel" option is still supported to preserve backward compatibility. Commands -------- * The "add_test()" command learned the option "COMMAND_EXPAND_LISTS" which causes lists in the "COMMAND" argument to be expanded, including lists created by generator expressions. * The "file()" command learned a new sub-command, "GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the list of libraries linked by an executable or library. This sub- command is intended as a replacement for "GetPrerequisites". * The "find_file()", "find_library()", "find_path()", "find_package()", and "find_program()" commands have learned to check the following variables to control searching * "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching the cmake-specific environment variables. * "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake- specific cache variables. * "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching cmake platform specific variables. * "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of "_ROOT" variables. * "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the searching the standard system environment variables. * The "find_package()" command has learned to check the following variables to control searching * "CMAKE_FIND_USE_PACKAGE_REGISTRY" - Controls the searching the cmake user registry. * The "message()" command learned indentation control with the new "CMAKE_MESSAGE_INDENT" variable. * The "target_precompile_headers()" command was added to specify a list of headers to precompile for faster compilation times. Variables --------- * The "CMAKE_CUDA_RESOLVE_DEVICE_SYMBOLS" variable has been introduced to optionally initialize the "CUDA_RESOLVE_DEVICE_SYMBOLS" target property. * The "CMAKE_ECLIPSE_RESOURCE_ENCODING" variable was added to specify the resource encoding for the the "Eclipse CDT4" extra generator. Properties ---------- * The "BUILD_RPATH" and "INSTALL_RPATH" target properties now support "generator expressions". * The "INSTALL_REMOVE_ENVIRONMENT_RPATH" target property was added to remove compiler-defined "RPATH" entries from a target. This property is initialized by the "CMAKE_INSTALL_REMOVE_ENVIRONMENT_RPATH" variable. * The "PRECOMPILE_HEADERS" target property was added to specify a list of headers to precompile for faster compilation times. Set it using the "target_precompile_headers()" command. * The "UNITY_BUILD" target property was added to tell generators to batch include source files for faster compilation times. * The "VS_CONFIGURATION_TYPE" target property now supports "generator expressions". * The "VS_DPI_AWARE" target property was added to tell Visual Studio Generators to set the "EnableDpiAwareness" property in ".vcxproj" files. * The "XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING" target property was added to tell the "Xcode" generator to set the value of the "Allow debugging when using document Versions Browser" schema option. Modules ------- * The "FindDoxygen" module "doxygen_add_docs()" command gained a new "USE_STAMP_FILE" option. When this option present, the custom target created by the command will only re-run Doxygen if any of the source files have changed since the last successful run. * The "FindGnuTLS" module now provides an imported target. * The "FindPackageHandleStandardArgs" module "find_package_handle_standard_args()" command gained a new "REASON_FAILURE_MESSAGE" option to specify a message giving the reason for the failure. * The "FindPkgConfig" module "pkg_search_module()" macro now defines a "_MODULE_NAME" result variable containing the first matching module name. * The "FindPython3" and "FindPython" modules gained options to control which "ABIs" will be searched. * The "FindPython3", "FindPython2", and "FindPython" modules now support direct specification of artifacts via cache entries. Autogen ------- * When using "AUTOMOC", CMake now generates the "-p" path prefix option for "moc". This ensures that "moc" output files are identical on different build setups (given, that the headers compiled by "moc" are in an "include directory"). Also it ensures that "moc" output files will compile correctly when the source and/or build directory is a symbolic link. The "moc" path prefix generation behavior can be configured by setting the new "CMAKE_AUTOMOC_PATH_PREFIX" variable and/or "AUTOMOC_PATH_PREFIX" target property. CTest ----- * "ctest(1)" now has the ability to serialize tests based on hardware requirements for each test. See Hardware Allocation for details. * A new test property, "SKIP_REGULAR_EXPRESSION", has been added. This property is similar to "FAIL_REGULAR_EXPRESSION" and "PASS_REGULAR_EXPRESSION", but with the same meaning as "SKIP_RETURN_CODE". This is useful, for example, in cases where the user has no control over the return code of the test. For example, in Catch2, the return value is the number of assertion failed, therefore it is impossible to use it for "SKIP_RETURN_CODE". CPack ----- * CPack variable "CPACK_INSTALL_CMAKE_CONFIGURATIONS" was added to control what configurations are to be packaged for multi- configuration CMake generators. * The "CPack DEB Generator" is now able to format generic text (usually used as the description for multiple CPack generators) according to the Debian Policy Manual. See the "CPACK_PACKAGE_DESCRIPTION_FILE" and "CPACK_DEBIAN__DESCRIPTION" variables. * The "CPack Archive Generator" learned to generate ".tar.zst" packages with Zstandard compression. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policy "CMP0067" ("CMP0066" and below were already deprecated). The "cmake- policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. * The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been deprecated. Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable instead. * The "GetPrerequisites" module has been deprecated, as it has been superceded by "file(GET_RUNTIME_DEPENDENCIES)". * The "CPACK_INSTALL_SCRIPT" variable has been deprecated in favor of the new, more accurately named "CPACK_INSTALL_SCRIPTS" variable. Other Changes ============= * The "cmake(1)" "-C " option now evaluates the initial cache script with "CMAKE_SOURCE_DIR" and "CMAKE_BINARY_DIR" set to the top-level source and build trees. * The "cmake(1)" "-E remove_directory" command-line tool, when given the path to a symlink to a directory, now removes just the symlink. It no longer removes content of the linked directory. * The "ctest(1)" "--build-makeprogram" command-line option now specifies the make program used when configuring a project with the "Ninja" generator or the Makefile Generators. * The "ExternalProject" module "ExternalProject_Add()" command has been updated so that "GIT_SUBMODULES """ initializes no submodules. See policy "CMP0097". * The "FindGTest" module has been updated to recognize MSVC build trees generated by GTest 1.8.1. * The "project()" command no longer strips leading zeros in version components. See policy "CMP0096". * The Qt Compressed Help file is now named "CMake.qch", which no longer contains the release version in the file name. When CMake is upgraded in-place, the name and location of this file will remain constant. Tools such as IDEs, help viewers, etc. should now be able to refer to this file at a fixed location that remains valid across CMake upgrades. * "RPATH" entries are properly escaped in the generated CMake scripts used for installation. See policy "CMP0095". * When using "CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS" on Windows the auto- generated exports are now updated only when the object files providing the symbols are updated. From paul at mad-scientist.net Thu Oct 10 18:21:51 2019 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 10 Oct 2019 18:21:51 -0400 Subject: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing) In-Reply-To: References: Message-ID: <17096d860f55751570ef7ab3a1831f47f8cf8cb2.camel@mad-scientist.net> On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote: > * The "UNITY_BUILD" target property was added to tell generators to > batch include source files for faster compilation times. Are there any instructions on how to make this work? I tried this: cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON . Then ran "make". The output showed I had just as many output .o files as input .cpp files and that make ran one compile command per .cpp file. Is there something else I need to do to enable unity builds in my cmake files, than just give the above option? The docs imply that the above is all that's needed. Cheers! From paul at mad-scientist.net Thu Oct 10 18:53:42 2019 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 10 Oct 2019 18:53:42 -0400 Subject: [CMake] Unity builds vs. compile_commands.json (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing) In-Reply-To: References: Message-ID: <685264e806beb348bdcfd5ebd9936f41a0bd2dff.camel@mad-scientist.net> On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote: > * The "UNITY_BUILD" target property was added to tell generators to > batch include source files for faster compilation times. For some reason this didn't work with my actual cmake environment, but I could enable it on a simple test environment. I can look into that later. Here my concern is that you cannot use unity builds if you need compile_commands.json (-DCMAKE_EXPORT_COMPILE_COMMANDS=ON); for example if this is required by your IDE or other build tools. When unity builds are enabled the json file is not usable since it contains only commands for the unity source files and doesn't describe the original source files. Is there an intent to address this before the 3.16 release? Or is this a known limitation, which may or may not be addressed in some future version of CMake? If the latter it should probably be added to the release notes and/or documentation for unity builds. Thanks! From Alan.W.Irwin1234 at gmail.com Fri Oct 11 01:28:26 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Thu, 10 Oct 2019 22:28:26 -0700 (PDT) Subject: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing) In-Reply-To: <17096d860f55751570ef7ab3a1831f47f8cf8cb2.camel@mad-scientist.net> References: <17096d860f55751570ef7ab3a1831f47f8cf8cb2.camel@mad-scientist.net> Message-ID: On 2019-10-10 18:21-0400 Paul Smith wrote: > On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote: >> * The "UNITY_BUILD" target property was added to tell generators to >> batch include source files for faster compilation times. > > Are there any instructions on how to make this work? I tried this: > > cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON . > > Then ran "make". The output showed I had just as many output .o files > as input .cpp files and that make ran one compile command per .cpp > file. > > Is there something else I need to do to enable unity builds in my cmake > files, than just give the above option? The docs imply that the above > is all that's needed. Hi Paul: I have never tried unity builds, but your question did inspire me to look at [the unity build documentation](https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html) which if you follow the links to other related documentation does imply what you have done above is correct and should by default group 8 source-code files into a lump to be compiled together. Since you are not getting that behaviour, I am wondering if one or more of the documented reasons for skipping unity builds is making a difference in your case. Those reasons are the following: "The source files marked by GENERATED will be skipped from unity build. This applies also for the source files marked with SKIP_UNITY_BUILD_INCLUSION. The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped." Good luck, and I hope you will keep the list informed of any further progress you make with your unity build experiments. 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 __________________________ From v.van.beveren at nikhef.nl Fri Oct 11 02:10:54 2019 From: v.van.beveren at nikhef.nl (Vincent van Beveren) Date: Fri, 11 Oct 2019 08:10:54 +0200 Subject: [CMake] Linking twice for CRC32 Message-ID: <9a48eafd-3625-0924-85de-a5091f7f7199@nikhef.nl> Hello? everyone, For integrating the CRC to an ELF I believe I will need to link twice. First to create a binary on which to caclulate the CRC, and using a second pass to actually put the CRC into a the symbol at the last part of the RAM. Using the pointers by Eric? Noulard I have constructed the following CMake code, which links the file, exports a binary BIN file (the actual ROM image, and then calculates the CRC into a file called $.crc32. # Exprimental CRC32 support add_library(clb_v2_dom.objs OBJECT ${F_GEN} ${F__DOM}) target_compile_definitions(clb_v2_dom.objs PUBLIC -DDOM -DCLBV2 ) add_executable(clb_v2_dom.elf $) add_custom_command(TARGET clb_v2_dom.elf POST_BUILD ??? COMMAND ${CMAKE_OBJCOPY} $ ${SECTIONS} -O binary $.bin ??? COMMAND ${Python_EXECUTABLE} ${CMAKE_SOURCE_DIR}/tools/crc32.py $.bin > $.crc32 ) with linker flags defined as # Bring up the linker add_link_options( ??? -nostartfiles ??? -nodefaultlibs ??? -Wl,--gc-sections ??? -nostdlib ??? -T ${CMAKE_SOURCE_DIR}/${P_SRC}/romram.ld ??? -Wl,--defsym=CRC_VALUE=0 ??? -Wl,--defsym=_start=0 ??? ) However, the last part is to link the file again with *exactly* the same invocation as the original linking, except for the '-Wl,--defsym=CRC_VALUE=<>' instead of 0. Can anyone give me points on how to achieve this goal? Kind regards, Vincent -- National Institute for Subatomic Physics Nikhef Department of Computer Technology Science Park 105 1098 XG AMSTERDAM tel. : +31 (0)20 592 2032 e-mail: v.van.beveren at nikhef.nl site : http://www.nikhef.nl/~vincentb From brad.king at kitware.com Fri Oct 11 08:15:34 2019 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Oct 2019 08:15:34 -0400 Subject: [CMake] Unity builds vs. compile_commands.json In-Reply-To: <685264e806beb348bdcfd5ebd9936f41a0bd2dff.camel@mad-scientist.net> References: <685264e806beb348bdcfd5ebd9936f41a0bd2dff.camel@mad-scientist.net> Message-ID: On 10/10/19 6:53 PM, Paul Smith wrote: > Is there an intent to address this before the 3.16 release? > > Or is this a known limitation, which may or may not be addressed in > some future version of CMake? > > If the latter it should probably be added to the release notes and/or > documentation for unity builds. I've opened an issue for it: * https://gitlab.kitware.com/cmake/cmake/issues/19826 This won't block the release so I've updated the documentation to mention this limitation. -Brad From smirnov.d.p.1997 at gmail.com Fri Oct 11 09:06:15 2019 From: smirnov.d.p.1997 at gmail.com (=?UTF-8?B?0JTQtdC90LjRgSDQodC80LjRgNC90L7Qsg==?=) Date: Fri, 11 Oct 2019 20:06:15 +0700 Subject: [CMake] Error because of MSVC_RUNTIME_LIBRARY value Message-ID: *Here is my root CMakeLists.txt file:* cmake_minimum_required(VERSION 3.15) cmake_policy(SET CMP0091 NEW) project(test_masm) set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$:Debug>") add_subdirectory(src) *Here is the src/CMakeLists.txt file:* enable_language(ASM_MASM) add_executable(test_executable main.asm) *src/main.asm is empty.* After run cmake.exe I get error "*MSVC_RUNTIME_LIBRARY value 'MultiThreadedDebug' not known for this ASM_MASM compiler*". *Here is the full listing:* cmake.exe -G "Visual Studio 16 2019" -A x64 .. -- The C compiler identification is MSVC 19.22.27905.0 -- The CXX compiler identification is MSVC 19.22.27905.0 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.22.27905/bin/Hostx64/x64/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.22.27905/bin/Hostx64/x64/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/2019/Community/VC/Tools/MSVC/14.22.27905/bin/Hostx64/x64/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.22.27905/bin/Hostx64/x64/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- The ASM_MASM compiler identification is MSVC -- Found assembler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.22.27905/bin/Hostx64/x64/ml64.exe -- Configuring done CMake Error in src/CMakeLists.txt: MSVC_RUNTIME_LIBRARY value 'MultiThreadedDebug' not known for this ASM_MASM compiler. -- Generating done CMake Generate step failed. Build files cannot be regenerated correctly. Can someone please tell me if I am doing something wrong or it's a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Fri Oct 11 10:17:33 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 11 Oct 2019 10:17:33 -0400 Subject: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing) In-Reply-To: References: <17096d860f55751570ef7ab3a1831f47f8cf8cb2.camel@mad-scientist.net> Message-ID: On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin wrote: > The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped." This is by far the most likely reason. We added this restriction because we don't want files that have different COMPILE_FLAGS etc. to be lumped together in a unity file. We decided that this was good enough as a first past, but the way forward is to intelligently group together files that have the same COMPILE_OPTIONS, COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES. Kyle From mellery451 at gmail.com Fri Oct 11 15:33:17 2019 From: mellery451 at gmail.com (Michael Ellery) Date: Fri, 11 Oct 2019 12:33:17 -0700 Subject: [CMake] target_sources vs. PUBLIC_HEADER for libraries Message-ID: <5384F831-F47E-4F36-A31D-938074ED5FB0@gmail.com> I?d like to make sure I understand two different aspects of header files management for libraries: (1) typically you can add header files to target_sources, but it?s only helpful for IDEs..so that the IDE will show the header files in its sources list, correct?. In theory, cmake does not actually need header files explicitly specified for dependency tracking, although I guess listing them makes it explicit. (2) setting the PUBLIC_HEADER property for a target then makes header files available for installation via the PUBLIC_HEADER destination. Is this the preferred way to install the library interface/public headers? How do you handle a header directory hierarchy ? for example maybe you have detail and impl subdirectories if you are following boost/stdlib conventions. I found Craig?s article about target_sources very helpful (https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/), but I don?t think it addresses the PUBLIC_HEADER installation use case. Thanks, Mike Ellery From fdk17 at ftml.net Fri Oct 11 16:37:13 2019 From: fdk17 at ftml.net (Fred Baksik) Date: Fri, 11 Oct 2019 16:37:13 -0400 Subject: [CMake] target_sources vs. PUBLIC_HEADER for libraries In-Reply-To: <5384F831-F47E-4F36-A31D-938074ED5FB0@gmail.com> References: <5384F831-F47E-4F36-A31D-938074ED5FB0@gmail.com> Message-ID: <41487723-843c-45d9-a9c1-3bb971d3a1c0@www.fastmail.com> On Fri, Oct 11, 2019, at 3:33 PM, Michael Ellery wrote: > I?d like to make sure I understand two different aspects of header files management for libraries: > > (1) typically you can add header files to target_sources, but it?s only helpful for IDEs..so that the IDE will show the header files in its sources list, correct?. In theory, cmake does not actually need header files explicitly specified for dependency tracking, although I guess listing them makes it explicit. My experience has been that adding a header file makes sure it?s listed in the IDE along with the other sources. Some IDEs will determine other non-listed headers and list them under a different folder. But I?ve never seen listing an unused header file getting added as a dependency so that changing it causes the target to get rebuilt. I?ve always had to make sure that the header is included in something that gets compiled. ? F -------------- next part -------------- An HTML attachment was scrubbed... URL: From i.zaufi at gmail.com Fri Oct 11 17:09:03 2019 From: i.zaufi at gmail.com (Alex Turbov) Date: Fri, 11 Oct 2019 23:09:03 +0200 Subject: [CMake] target_sources vs. PUBLIC_HEADER for libraries In-Reply-To: <5384F831-F47E-4F36-A31D-938074ED5FB0@gmail.com> References: <5384F831-F47E-4F36-A31D-938074ED5FB0@gmail.com> Message-ID: Hi, On Fri, Oct 11, 2019 at 9:33 PM Michael Ellery wrote: > I?d like to make sure I understand two different aspects of header files > management for libraries: > > (1) typically you can add header files to target_sources, but it?s only > helpful for IDEs..so that the IDE will show the header files in its sources > list, correct?. In theory, cmake does not actually need header files > explicitly specified for dependency tracking, although I guess listing them > makes it explicit. > yep, correct > (2) setting the PUBLIC_HEADER property for a target then makes header > files available for installation via the PUBLIC_HEADER destination. Is this > the preferred way to install the library interface/public headers? How do > you handle a header directory hierarchy ? for example maybe you have detail > and impl subdirectories if you are following boost/stdlib conventions. > > Nowadays this feature useless if you have a directory hierarchy %( So pity... > I found Craig?s article about target_sources very helpful ( > https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/), > but I don?t think it addresses the PUBLIC_HEADER installation use case. > Yep, it describes a trivial ("Hello World" level) projects. Some time ago I've started a discussion about improvements to `target_sources` addressed to resolve directory hierarchy install problem, but it ends w/ no outcome... %( > Thanks, > Mike Ellery > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alaitsev at gmail.com Fri Oct 11 19:13:52 2019 From: alaitsev at gmail.com (Innokentiy Alaytsev) Date: Fri, 11 Oct 2019 16:13:52 -0700 (MST) Subject: [CMake] target_sources vs. PUBLIC_HEADER for libraries In-Reply-To: <5384F831-F47E-4F36-A31D-938074ED5FB0@gmail.com> References: <5384F831-F47E-4F36-A31D-938074ED5FB0@gmail.com> Message-ID: <1570835632752-0.post@n2.nabble.com> Hello! After some look into target installation, I've devised the following abomination . It is ugly and not the way it should be done, but it works and only requires some discipline at copying and pasting header files listing code. The function expects the files that are to be installed to be listed with BUILD_INTERFACE and INSTALL_INTERFACE generator expressions. I only use it for headers because I don't know how to separate file lists into components (i.e. Dev for headers and Runtime for resource files required at runtime). I use the following code for listing target header files: set (HEADERS # List of files here ) file(RELATIVE_PATH PREFIX ${PROJECT_SOURCE_DIR} ${CMAKE_CURRENT_LIST_DIR}) foreach (HEADER IN LISTS HEADERS) target_sources (my_target(s) PRIVATE $ $) endforeach (HEADER IN HEADERS) Hope that will somewhat help and won't hurt anyone's fillings and mind. Best regards, Innokentiy Alaytsev -- Sent from: http://cmake.3232098.n2.nabble.com/ From paul at mad-scientist.net Sat Oct 12 15:40:46 2019 From: paul at mad-scientist.net (Paul Smith) Date: Sat, 12 Oct 2019 15:40:46 -0400 Subject: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing) In-Reply-To: References: <17096d860f55751570ef7ab3a1831f47f8cf8cb2.camel@mad-scientist.net> Message-ID: On Fri, 2019-10-11 at 10:17 -0400, Kyle Edwards wrote: > On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin > < > Alan.W.Irwin1234 at gmail.com > > wrote: > > The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, > > COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped." > > This is by far the most likely reason. We added this restriction > because we don't want files that have different COMPILE_FLAGS etc. to > be lumped together in a unity file. We decided that this was good > enough as a first past, but the way forward is to intelligently group > together files that have the same COMPILE_OPTIONS, > COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES. I saw this in the manual, and I interpreted it to mean that if we used something like set_source_files_properties() or set_property(SOURCE) to set these properties on specific source files, then those files which are impacted by this won't be part of unity builds. That seems quite sensible to me. However, I don't do that hardly anywhere at all; maybe one or two files have an extra INCLUDE_DIRECTORIES setting or similar. Virtually all my properties are set on a per-target basis, so I assumed they wouldn't be an issue here. Am I misunderstanding that? It's also possible that a previous attempt to introduce unity builds to our setup via cotire is interfering with the new, standardized unity builds. I am not too familiar with the details of that but I can try to look into it. From Alan.W.Irwin1234 at gmail.com Sat Oct 12 22:25:02 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Sat, 12 Oct 2019 19:25:02 -0700 (PDT) Subject: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing) In-Reply-To: References: <17096d860f55751570ef7ab3a1831f47f8cf8cb2.camel@mad-scientist.net> Message-ID: On 2019-10-12 15:40-0400 Paul Smith wrote: > On Fri, 2019-10-11 at 10:17 -0400, Kyle Edwards wrote: >> On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin >> < >> Alan.W.Irwin1234 at gmail.com >>> wrote: >>> The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, >>> COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped." >> >> This is by far the most likely reason. We added this restriction >> because we don't want files that have different COMPILE_FLAGS etc. to >> be lumped together in a unity file. We decided that this was good >> enough as a first past, but the way forward is to intelligently group >> together files that have the same COMPILE_OPTIONS, >> COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES. > > I saw this in the manual, and I interpreted it to mean that if we used > something like set_source_files_properties() or set_property(SOURCE) to > set these properties on specific source files, then those files which > are impacted by this won't be part of unity builds. > > That seems quite sensible to me. > > However, I don't do that hardly anywhere at all; maybe one or two files > have an extra INCLUDE_DIRECTORIES setting or similar. > > Virtually all my properties are set on a per-target basis, so I assumed > they wouldn't be an issue here. > > Am I misunderstanding that? I think the current documentation is ambiguous about this. But certain target and directory properties can affect the flags used to compile the source code just as much as source code properties. So I am virtually positive the implementation has to pay attention to all these sources of properties to decide what can/cannot be lumped into a Unity source file. If Kyle confirms this guess, then the documentation should be changed accordingly to remove the ambiguity about this. 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 __________________________ From paul at mad-scientist.net Sun Oct 13 17:15:04 2019 From: paul at mad-scientist.net (Paul Smith) Date: Sun, 13 Oct 2019 17:15:04 -0400 Subject: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing) In-Reply-To: References: <17096d860f55751570ef7ab3a1831f47f8cf8cb2.camel@mad-scientist.net> Message-ID: <33b41d83295b620f70622ccbb062852452392d9f.camel@mad-scientist.net> On Sat, 2019-10-12 at 19:25 -0700, Alan W. Irwin wrote: > > Virtually all my properties are set on a per-target basis, so I assumed > > they wouldn't be an issue here. > > > > Am I misunderstanding that? > > I think the current documentation is ambiguous about this. But > certain target and directory properties can affect the flags used to > compile the source code just as much as source code properties. So I > am virtually positive the implementation has to pay attention to all > these sources of properties to decide what can/cannot be lumped into a > Unity source file. If Kyle confirms this guess, then the > documentation should be changed accordingly to remove the ambiguity > about this. I know no more than you but I'm quite sure that it's not the case that adding library/executable-level options can cause unity to be disabled. I've never heard of _ANY_ such target that didn't have at least some properties defined for it. A unity source file can lump together N real source files from the same target (library/executable) as long as those files don't have extra source-specific flags, because all other files in a given target have the same flags. From sancelot at numalliance.com Mon Oct 14 04:49:24 2019 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Mon, 14 Oct 2019 10:49:24 +0200 Subject: [CMake] finding cdk Message-ID: Hi, I have got some problems finding cdk lib in my debian system I used find_library without success libcdk can be found in /usr/lib/x86_64-linux-gnu/ and cdk in include system path cdk/cdk.h Regards, S.Ancelot -------------- next part -------------- An HTML attachment was scrubbed... URL: From edo.paskino at gmail.com Mon Oct 14 07:00:06 2019 From: edo.paskino at gmail.com (Edoardo Pasca) Date: Mon, 14 Oct 2019 12:00:06 +0100 Subject: [CMake] error executing script with cmake -P Message-ID: Dear all, I am using external project. I would like to patch a source file. I came out with a cmake script that does the string replacement I'm interested in. I tested in a standalone project, with the following CMakeLists.txt cmake_minimum_required(VERSION 3.4) project(patching_string) file (STRINGS TestData.py testdata NEWLINE_CONSUME) string(REPLACE "sys.prefix" "os.environ[\'SIRF_INSTALL_PATH\']" patched ${testdata}) file( WRITE ${CMAKE_CURRENT_SOURCE_DIR}/TestData.py ${patched} ) and as a matter of facts this does the string replacement I'm interested in. Good, now I would like to use this to the project I'm really interested in which uses the ExternalProject_Add machinery. I added the patch step: file (WRITE ${CMAKE_BINARY_DIR}/patch_script.cmake " file (STRINGS ${${proj}_SOURCE_DIR}/Wrappers/Python/ccpi/framework/TestData.py testdata NEWLINE_CONSUME) string(REPLACE \"sys.prefix\" \"os.environ[\\\'SIRF_INSTALL_PATH\\\']\" patched \${testdata}) file( WRITE ${${proj}_SOURCE_DIR}/Wrappers/Python/ccpi/framework/TestData.py \${patched} ) ") ExternalProject_Add( ... PATCH_COMMAND ${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/patch_script.cmake ... ) Notice that I write the patch_script.cmake before the ExternalProject_Add Now, all of this WORKS. Or at least I get the patch_script.cmake file in the proper directoty, with the content I want. However, execution with cmake -P patch_script.cmake doesn't work as expected. I get CMake Error at build/patch_script.cmake:3 (string): string sub-command REPLACE requires at least four arguments. Given that the patch_script.cmake has the same content of the standalone CMakeLists.txt above (without the first 2 lines), I don't know where things don't go well, except that I execute the script with cmake -P cmake version 3.15.2 Thanks for any help. Edo -- Edo I know you think you understand what you thought I said, but I'm not sure you realize that what you heard is not what I meant (prob. Alan Greenspan) :wq -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Oct 14 08:33:36 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 14 Oct 2019 08:33:36 -0400 Subject: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing) In-Reply-To: <17096d860f55751570ef7ab3a1831f47f8cf8cb2.camel@mad-scientist.net> References: <17096d860f55751570ef7ab3a1831f47f8cf8cb2.camel@mad-scientist.net> Message-ID: Hi Paul, As another reference point, I verified that -DCMAKE_UNITY_BUILD=ON works with the VTK-m ( https://gitlab.kitware.com/vtk/vtk-m ) project. I only verified using a clean CMake 3.16 build directory. On Thu, Oct 10, 2019 at 6:43 PM Paul Smith wrote: > > On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote: > > * The "UNITY_BUILD" target property was added to tell generators to > > batch include source files for faster compilation times. > > Are there any instructions on how to make this work? I tried this: > > cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON . > > Then ran "make". The output showed I had just as many output .o files > as input .cpp files and that make ran one compile command per .cpp > file. > > Is there something else I need to do to enable unity builds in my cmake > files, than just give the above option? The docs imply that the above > is all that's needed. > > Cheers! > > -- > > 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 From david.aldrich.ntml at gmail.com Mon Oct 14 09:13:19 2019 From: david.aldrich.ntml at gmail.com (David Aldrich) Date: Mon, 14 Oct 2019 14:13:19 +0100 Subject: [CMake] How to make a hierarchical application using CMake? Message-ID: Hi I am trying to convert a large software project from makefiles to CMake. The project is organised as a set of shared ?star? libraries, linked to a static ?kernel? library. The current directory arrangement is: |--stars | |-- star1_lib | |-- source files | |-- makefile | |-- star2_lib | |-- source files | |-- makefile | |-- solibs | |-- Release | |-- .so files | |--kernel | |-- source files | |-- makefile | |-- Release | |-- kernel.a | |--application |-- makefile |-- Release |-- myapp.exe In high-level terms, how could I implement this using CMake, such that invoking ?make? in directory ?application? invokes a make of each shared and static library, and links them to form ?myapp.exe?? (I understand the basics of CMake, the issue here is how to handle the make of source code and libraries spread across a directory hierarchy). Best regards David -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdk17 at ftml.net Mon Oct 14 14:10:54 2019 From: fdk17 at ftml.net (Fred Baksik) Date: Mon, 14 Oct 2019 14:10:54 -0400 Subject: [CMake] How to make a hierarchical application using CMake? In-Reply-To: References: Message-ID: <621389ce-6d81-48f7-96a2-71cbb3e464db@www.fastmail.com> On Mon, Oct 14, 2019, at 9:13 AM, David Aldrich wrote: > Hi > > I am trying to convert a large software project from makefiles to CMake. The project is organised as a set of shared ?star? libraries, linked to a static ?kernel? library. The current directory arrangement is: > > |--stars > | |-- star1_lib > | |-- source files > | |-- makefile > | |-- star2_lib > | |-- source files > | |-- makefile > | |-- solibs > | |-- Release > | |-- .so files > | > |--kernel > | |-- source files > | |-- makefile > | |-- Release > | |-- kernel.a > | > |--application > |-- makefile > |-- Release > |-- myapp.exe > > In high-level terms, how could I implement this using CMake, such that invoking ?make? in directory ?application? invokes a make of each shared and static library, and links them to form ?myapp.exe?? > > (I understand the basics of CMake, the issue here is how to handle the make of source code and libraries spread across a directory hierarchy). > > Best regards > > David > > add_subdirectory() can accept relative paths to outside the "root" source tree. So the main CMakeLists.txt would be located in ./application. Then do: add_subdirectory(../kernel kernel) add_subdirectory(../stars/stars1_lib stars1_lib) ./kernel/CMakeLists.txt would list it's files, and etcetera. I've use this method in the past for handling applications that are meant to target Windows, Linux, and embedded systems. Then by using variables to determine with platform / target ertain kernel and library characteristics are used. Everything is built in the build directory for that particular platform / target. This allows for app_target1, app_target2, app_target3, ..., build directories to be totally independent. -- F -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Mon Oct 14 15:52:55 2019 From: d3ck0r at gmail.com (J Decker) Date: Mon, 14 Oct 2019 12:52:55 -0700 Subject: [CMake] How to make a hierarchical application using CMake? In-Reply-To: <621389ce-6d81-48f7-96a2-71cbb3e464db@www.fastmail.com> References: <621389ce-6d81-48f7-96a2-71cbb3e464db@www.fastmail.com> Message-ID: In the build directory, the build rules are generally like the would be in the source too... so you can just go into src/libwhatever and do 'make' in that branch. like if your target was visual studio or some IDE, you could click on a single project to build, and it would of course check and build related projects. basically you don't even need ../ inclusions just a root that add_subdirectory( lib1 ) ... 2, 3, utils (which itself adds other utiliy thins that reference other lib targets )... On Mon, Oct 14, 2019 at 11:11 AM Fred Baksik wrote: > > > On Mon, Oct 14, 2019, at 9:13 AM, David Aldrich wrote: > > Hi > > > > I am trying to convert a large software project from makefiles to CMake. > The project is organised as a set of shared ?star? libraries, linked to a > static ?kernel? library. The current directory arrangement is: > > > > |--stars > > | |-- star1_lib > > | |-- source files > > | |-- makefile > > | |-- star2_lib > > | |-- source files > > | |-- makefile > > | |-- solibs > > | |-- Release > > | |-- .so files > > | > > |--kernel > > | |-- source files > > | |-- makefile > > | |-- Release > > | |-- kernel.a > > | > > |--application > > |-- makefile > > |-- Release > > |-- myapp.exe > > > > In high-level terms, how could I implement this using CMake, such that > invoking ?make? in directory ?application? invokes a make of each shared > and static library, and links them to form ?myapp.exe?? > > > > (I understand the basics of CMake, the issue here is how to handle the > make of source code and libraries spread across a directory hierarchy). > > > > Best regards > > > > David > > > > add_subdirectory() can accept relative paths to outside the "root" source > tree. > So the main CMakeLists.txt would be located in ./application. > Then do: > add_subdirectory(../kernel kernel) > add_subdirectory(../stars/stars1_lib stars1_lib) > > ./kernel/CMakeLists.txt would list it's files, and etcetera. > > I've use this method in the past for handling applications that are meant > to target Windows, Linux, and embedded systems. > Then by using variables to determine with platform / target ertain kernel > and library characteristics are used. > Everything is built in the build directory for that particular platform / > target. > This allows for app_target1, app_target2, app_target3, ..., build > directories to be totally independent. > > -- > F > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.W.Irwin1234 at gmail.com Mon Oct 14 16:03:39 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Mon, 14 Oct 2019 13:03:39 -0700 (PDT) Subject: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing) In-Reply-To: <33b41d83295b620f70622ccbb062852452392d9f.camel@mad-scientist.net> References: <17096d860f55751570ef7ab3a1831f47f8cf8cb2.camel@mad-scientist.net> <33b41d83295b620f70622ccbb062852452392d9f.camel@mad-scientist.net> Message-ID: On 2019-10-13 17:15-0400 Paul Smith wrote: > A unity source file can lump together N real source files from the same > target (library/executable) as long as those files don't have extra > source-specific flags, because all other files in a given target have > the same flags. I agree that it is not at all clear whether this is the cause of the issue. So I will stop speculating about that cause even though that is a fun activity. :-) Nevertheless, it does sound like your complex test case does expose some issue with EITHER how you have implemented the build system for your complex case OR how CMake currently rejects certain builds from being included in Unity builds. So to figure out which it is, I think your next step should be to attempt to implement the simplest possible self-contained test case that illustrates the Unity exclusion issue you have found. I believe that course has already been suggested in this thread so I am seconding that motion. My own experiences with such implementations is I often cannot demonstrate the issue in a simple way, i.e., the "CMake bug" often tends to be due to an issue with my implementation of the build system for the complex case. However, when I have demonstrated with such a simple test case there really is a CMake bug, that test case normally helps CMake developers in a big way to find and fix the issue. 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 __________________________ From artiom.blinovas at gmail.com Mon Oct 14 16:47:32 2019 From: artiom.blinovas at gmail.com (Artiom Blinovas) Date: Mon, 14 Oct 2019 22:47:32 +0200 Subject: [CMake] Sending you config file of an unknown system Platform/MINGW64_NT-10.0-17763 In-Reply-To: References: Message-ID: If it makes sense one could add mingw platform so next time cmake won't speak warnings -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # This is the CMakeCache file. # For build in directory: /home/user/project/blatt-1-aufgabe-3-tendermonster/build # It was generated by CMake: /usr/bin/cmake.exe # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. ######################## # EXTERNAL cache entries ######################## //Path to a program. CMAKE_AR:FILEPATH=/mingw64/bin/ar.exe //Choose the type of build, options are: None Debug Release RelWithDebInfo // MinSizeRel ... CMAKE_BUILD_TYPE:STRING= //Enable/Disable color output during build. CMAKE_COLOR_MAKEFILE:BOOL=ON //CXX compiler CMAKE_CXX_COMPILER:FILEPATH=/mingw64/bin/g++.exe //A wrapper around 'ar' adding the appropriate '--plugin' option // for the GCC compiler CMAKE_CXX_COMPILER_AR:FILEPATH=/mingw64/bin/gcc-ar.exe //A wrapper around 'ranlib' adding the appropriate '--plugin' option // for the GCC compiler CMAKE_CXX_COMPILER_RANLIB:FILEPATH=/mingw64/bin/gcc-ranlib.exe //Flags used by the CXX compiler during all build types. CMAKE_CXX_FLAGS:STRING= //Flags used by the CXX compiler during DEBUG builds. CMAKE_CXX_FLAGS_DEBUG:STRING=-g //Flags used by the CXX compiler during MINSIZEREL builds. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the CXX compiler during RELEASE builds. CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the CXX compiler during RELWITHDEBINFO builds. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //C compiler CMAKE_C_COMPILER:FILEPATH=/mingw64/bin/gcc.exe //A wrapper around 'ar' adding the appropriate '--plugin' option // for the GCC compiler CMAKE_C_COMPILER_AR:FILEPATH=/mingw64/bin/gcc-ar.exe //A wrapper around 'ranlib' adding the appropriate '--plugin' option // for the GCC compiler CMAKE_C_COMPILER_RANLIB:FILEPATH=/mingw64/bin/gcc-ranlib.exe //Flags used by the C compiler during all build types. CMAKE_C_FLAGS:STRING= //Flags used by the C compiler during DEBUG builds. CMAKE_C_FLAGS_DEBUG:STRING=-g //Flags used by the C compiler during MINSIZEREL builds. CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the C compiler during RELEASE builds. CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the C compiler during RELWITHDEBINFO builds. CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //Flags used by the linker during all build types. CMAKE_EXE_LINKER_FLAGS:STRING= //Flags used by the linker during DEBUG builds. CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during MINSIZEREL builds. CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during RELEASE builds. CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during RELWITHDEBINFO builds. CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Enable/Disable output of compile commands during generation. CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF //Install path prefix, prepended onto install directories. CMAKE_INSTALL_PREFIX:PATH=/usr/local //Path to a program. CMAKE_LINKER:FILEPATH=/mingw64/bin/ld.exe //Path to a program. CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make.exe //Flags used by the linker during the creation of modules during // all build types. CMAKE_MODULE_LINKER_FLAGS:STRING= //Flags used by the linker during the creation of modules during // DEBUG builds. CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during the creation of modules during // MINSIZEREL builds. CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during the creation of modules during // RELEASE builds. CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during the creation of modules during // RELWITHDEBINFO builds. CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Path to a program. CMAKE_NM:FILEPATH=/mingw64/bin/nm.exe //Path to a program. CMAKE_OBJCOPY:FILEPATH=/mingw64/bin/objcopy.exe //Path to a program. CMAKE_OBJDUMP:FILEPATH=/mingw64/bin/objdump.exe //Value Computed by CMake CMAKE_PROJECT_DESCRIPTION:STATIC= //Value Computed by CMake CMAKE_PROJECT_HOMEPAGE_URL:STATIC= //Value Computed by CMake CMAKE_PROJECT_NAME:STATIC=main //Path to a program. CMAKE_RANLIB:FILEPATH=/mingw64/bin/ranlib.exe //Flags used by the linker during the creation of shared libraries // during all build types. CMAKE_SHARED_LINKER_FLAGS:STRING= //Flags used by the linker during the creation of shared libraries // during DEBUG builds. CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during the creation of shared libraries // during MINSIZEREL builds. CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during the creation of shared libraries // during RELEASE builds. CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during the creation of shared libraries // during RELWITHDEBINFO builds. CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING= //If set, runtime paths are not added when installing shared libraries, // but are added when building. CMAKE_SKIP_INSTALL_RPATH:BOOL=NO //If set, runtime paths are not added when using shared libraries. CMAKE_SKIP_RPATH:BOOL=NO //Flags used by the linker during the creation of static libraries // during all build types. CMAKE_STATIC_LINKER_FLAGS:STRING= //Flags used by the linker during the creation of static libraries // during DEBUG builds. CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during the creation of static libraries // during MINSIZEREL builds. CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during the creation of static libraries // during RELEASE builds. CMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during the creation of static libraries // during RELWITHDEBINFO builds. CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Path to a program. CMAKE_STRIP:FILEPATH=/mingw64/bin/strip.exe //If this value is on, makefiles will be generated without the // .SILENT directive, and all commands will be echoed to the console // during the make. This is useful for debugging only. With Visual // Studio IDE projects all commands are done without /nologo. CMAKE_VERBOSE_MAKEFILE:BOOL=FALSE //Value Computed by CMake main_BINARY_DIR:STATIC=/home/user/project/blatt-1-aufgabe-3-tendermonster/build //Value Computed by CMake main_SOURCE_DIR:STATIC=/home/user/project/blatt-1-aufgabe-3-tendermonster ######################## # INTERNAL cache entries ######################## //ADVANCED property for variable: CMAKE_AR CMAKE_AR-ADVANCED:INTERNAL=1 //This is the directory where this CMakeCache.txt was created CMAKE_CACHEFILE_DIR:INTERNAL=/home/user/project/blatt-1-aufgabe-3-tendermonster/build //Major version of cmake used to create the current loaded cache CMAKE_CACHE_MAJOR_VERSION:INTERNAL=3 //Minor version of cmake used to create the current loaded cache CMAKE_CACHE_MINOR_VERSION:INTERNAL=15 //Patch version of cmake used to create the current loaded cache CMAKE_CACHE_PATCH_VERSION:INTERNAL=4 //ADVANCED property for variable: CMAKE_COLOR_MAKEFILE CMAKE_COLOR_MAKEFILE-ADVANCED:INTERNAL=1 //Path to CMake executable. CMAKE_COMMAND:INTERNAL=/usr/bin/cmake.exe //Path to cpack program executable. CMAKE_CPACK_COMMAND:INTERNAL=/usr/bin/cpack.exe //Path to ctest program executable. CMAKE_CTEST_COMMAND:INTERNAL=/usr/bin/ctest.exe //ADVANCED property for variable: CMAKE_CXX_COMPILER CMAKE_CXX_COMPILER-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_COMPILER_AR CMAKE_CXX_COMPILER_AR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_COMPILER_RANLIB CMAKE_CXX_COMPILER_RANLIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_RELWITHDEBINFO CMAKE_CXX_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_COMPILER CMAKE_C_COMPILER-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_COMPILER_AR CMAKE_C_COMPILER_AR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_COMPILER_RANLIB CMAKE_C_COMPILER_RANLIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS CMAKE_C_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Path to cache edit program executable. CMAKE_EDIT_COMMAND:INTERNAL=/usr/bin/ccmake.exe //Executable file format CMAKE_EXECUTABLE_FORMAT:INTERNAL=Unknown //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS CMAKE_EXE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_DEBUG CMAKE_EXE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_MINSIZEREL CMAKE_EXE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELEASE CMAKE_EXE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXPORT_COMPILE_COMMANDS CMAKE_EXPORT_COMPILE_COMMANDS-ADVANCED:INTERNAL=1 //Name of external makefile project generator. CMAKE_EXTRA_GENERATOR:INTERNAL= //Name of generator. CMAKE_GENERATOR:INTERNAL=Unix Makefiles //Generator instance identifier. CMAKE_GENERATOR_INSTANCE:INTERNAL= //Name of generator platform. CMAKE_GENERATOR_PLATFORM:INTERNAL= //Name of generator toolset. CMAKE_GENERATOR_TOOLSET:INTERNAL= //Source directory with the top level CMakeLists.txt file for this // project CMAKE_HOME_DIRECTORY:INTERNAL=/home/user/project/blatt-1-aufgabe-3-tendermonster //ADVANCED property for variable: CMAKE_LINKER CMAKE_LINKER-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MAKE_PROGRAM CMAKE_MAKE_PROGRAM-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_DEBUG CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELEASE CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_NM CMAKE_NM-ADVANCED:INTERNAL=1 //number of local generators CMAKE_NUMBER_OF_MAKEFILES:INTERNAL=1 //ADVANCED property for variable: CMAKE_OBJCOPY CMAKE_OBJCOPY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_OBJDUMP CMAKE_OBJDUMP-ADVANCED:INTERNAL=1 //Platform information initialized CMAKE_PLATFORM_INFO_INITIALIZED:INTERNAL=1 //ADVANCED property for variable: CMAKE_RANLIB CMAKE_RANLIB-ADVANCED:INTERNAL=1 //Path to CMake installation. CMAKE_ROOT:INTERNAL=/usr/share/cmake-3.15.4 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_DEBUG CMAKE_SHARED_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELEASE CMAKE_SHARED_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SKIP_INSTALL_RPATH CMAKE_SKIP_INSTALL_RPATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SKIP_RPATH CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS CMAKE_STATIC_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_DEBUG CMAKE_STATIC_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELEASE CMAKE_STATIC_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STRIP CMAKE_STRIP-ADVANCED:INTERNAL=1 //uname command CMAKE_UNAME:INTERNAL=/usr/bin/uname.exe //ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1 From ewmailing at gmail.com Mon Oct 14 17:27:01 2019 From: ewmailing at gmail.com (Eric Wing) Date: Mon, 14 Oct 2019 14:27:01 -0700 Subject: [CMake] Mac Xcode 11 Generator bug/problem with CODE_SIGN_IDENTITY default Message-ID: I hit a problem with the CMake/Xcode Generator using Xcode 11. (I think this problem started in Xcode 10 actually, but now I'm blocked really hard and need to solve this.) By default, Xcode is now trying to do "Sign to run locally" for the Code Signing Identity (CODE_SIGN_IDENTITY) property, by default. For trivial apps with no embedded libraries/frameworks, this seems to get through. However, for my real, more complicated projects, I have bundled libraries/frameworks. But since CMake doesn't really have full support for Xcode signing, the embedded libraries/frameworks are not signed, and the code sign process to local sign the .app fails. So to workaround this, I would like to tell Xcode to disable code signing entirely. Unfortunately, the only way to disable this seems to be to set the CODE_SIGN_IDENTITY to "", i.e. make the field completely blank. The following link shows all the steps with pictures, but basically you set the box to "Other" and then submit a completely blank input box. This internally in the Xcode project sets CODE_SIGN_IDENTITY to "". https://stackoverflow.com/a/54296008 But my problem in CMake is that when I try to set the Xcode property to "", it ignores the setting and defer to Xcode's default value of "Sign to run locally". # This has no effect set_property(TARGET ${my_app} PROPERTY XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "") How can I force this property to be overridden with ""? Thanks, Eric From noloader at gmail.com Tue Oct 15 01:05:44 2019 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 15 Oct 2019 01:05:44 -0400 Subject: [CMake] CMake 3.15 fails to install on OS X Message-ID: I'm building CMake cmake-3.15.4.tar.gz on OS X 10.12. The machine is stripped down, and only has the COmmand Line tools. No Xcode and friends. I configured with: ./configure --prefix=/usr Configure appears OK. Make appears OK. Install is failing: $ sudo make install VERBOSE=1 ... [100%] Built target foo /Users/jwalton/cmake-3.15.4/Bootstrap.cmk/cmake -E cmake_progress_start /Users/jwalton/cmake-3.15.4/CMakeFiles 0 /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/Makefile2 preinstall make[1]: Nothing to be done for `preinstall'. Install the project... bin/cmake -P cmake_install.cmake -- Install configuration: "" CMake Error at Source/kwsys/cmake_install.cmake:36 (file): file cannot create directory: /usr/doc/cmake-3.15/cmsys. Maybe need administrative privileges. Call Stack (most recent call first): cmake_install.cmake:37 (include) make: *** [install] Error 1 From doenges at mvtec.com Tue Oct 15 01:36:54 2019 From: doenges at mvtec.com (Eric Doenges) Date: Tue, 15 Oct 2019 07:36:54 +0200 Subject: [CMake] CMake 3.15 fails to install on OS X In-Reply-To: References: Message-ID: System Integrity Protection (SIP, introduced with macOS 10.11) prevents you from writing into various system directories (like /usr) even as the root user. You can either install cmake to a different location (like /usr/local, which apparently is not protected), or disable SIP entirely (which is not recommended). See this Wikipedia article for more information on SIP. Am 15.10.19 um 07:05 schrieb Jeffrey Walton: > I'm building CMake cmake-3.15.4.tar.gz on OS X 10.12. The machine is > stripped down, and only has the COmmand Line tools. No Xcode and > friends. > > I configured with: > > ./configure --prefix=/usr > > Configure appears OK. Make appears OK. Install is failing: > > $ sudo make install VERBOSE=1 > ... > [100%] Built target foo > /Users/jwalton/cmake-3.15.4/Bootstrap.cmk/cmake -E > cmake_progress_start /Users/jwalton/cmake-3.15.4/CMakeFiles 0 > /Library/Developer/CommandLineTools/usr/bin/make -f > CMakeFiles/Makefile2 preinstall > make[1]: Nothing to be done for `preinstall'. > Install the project... > bin/cmake -P cmake_install.cmake > -- Install configuration: "" > CMake Error at Source/kwsys/cmake_install.cmake:36 (file): > file cannot create directory: /usr/doc/cmake-3.15/cmsys. Maybe need > administrative privileges. > Call Stack (most recent call first): > cmake_install.cmake:37 (include) > > make: *** [install] Error 1 -- *Dr. Eric D?nges* Senior Software Engineer MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany doenges at mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com Find our privacy policy here . Sign up for our MVTec Newsletter! Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt Amtsgericht M?nchen HRB 114695 MVTec Software GmbH Logo -------------- next part -------------- An HTML attachment was scrubbed... URL: From musteresel at gmail.com Tue Oct 15 07:26:11 2019 From: musteresel at gmail.com (Daniel Oertwig) Date: Tue, 15 Oct 2019 13:26:11 +0200 Subject: [CMake] Can I use a *Targets-someName.cmake file to get access to _IMPORT_PREFIX ? In-Reply-To: References: Message-ID: TL;DR: - For a project thing I get thingTargets.cmake when I install EXPORT it - thingTargets.cmake sets _IMPORT_PREFIX - thingTargets.cmake loads files thingTargets-*.cmake Can I create and install thingTargets-someName.cmake which uses _IMPORT_PREFIX to "hook" into above mechanism? Or is this likely to break / change in the future? Longer version: I really like that you can use the exported targets of cmake even when still in a staging directory and not installed. Example: # in thing project mkdir thing-build; cd thing-build cmake .. -DCMAKE_INSTALL_PREFIX="" make # creates /path/to/staging/lib/cmake/thing/lib{Config,Targets}.cmake and friends make install DESTDIR=/path/to/staging # in user project mkdir user-build cmake .. -Dthing_DIR=/path/to/staging/lib/cmake/thing make # correctly uses libraries and headers from /path/to/staging/ Looking at /path/to/staging/lib/cmake/thing/libTargets.cmake I can see that it calculates an _IMPORT_PREFIX variable (in this case to /path/to/staging/ while not yet installed). Also it loads files named libTargets-*.cmake (of which there's only one for me, namely libTargets-noconfig.cmake). Can I install a file libTargets-someName.cmake? In this file I'd have access to the _IMPORT_PREFIX variable to e.g. set paths: target_link_options(thing::lib INTERFACE -T ${_IMPORT_PREFIX}/share/link.ld) Larger example at https://github.com/musteresel/cmake-multiple-example-research Best, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomfinegan at google.com Tue Oct 15 14:00:28 2019 From: tomfinegan at google.com (Tom Finegan) Date: Tue, 15 Oct 2019 11:00:28 -0700 Subject: [CMake] error executing script with cmake -P In-Reply-To: References: Message-ID: It looks like you aren't passing the $testdata variable down to the script. >From your message it looks like you need to add the following to your PATCH_COMMAND: -Dtestdata=${testdata} You must explicitly pass $testdata (and any other variables defined in the calling script) to patch_script.cmake via -D parameters on the command line. Also note that the -Dvar=value args must precede the -P