Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries
Clang and GCC making symbols visible by default (see my CppCon 2019 talk <https://crascit.com/2019/10/16/cppcon-2019-deep-cmake-for-library-authors/> for a discussion of this and the CMake features related to it). > > * For static libraries always uses the PUBLIC TLL option. > The right choice of PUBLIC, PRIVATE or INTERFACE is independent of whether the libraries are static or shared. > > These decisions were based on my own understanding of transitive > linking needs for static Unix libraries and shared and static Windows > libraries many years ago, but now it appears that understanding is out > of date or else was wrong in the first place. > > For example, in the static Linux case there is a nasty leakage of > compile and link flags between static libraries that I have just > tripped over when dealing with the D ldc2 compiler which cannot > understand those flags which are generated for the gcc compiler for a > C library which our D library depends on. So to stop that leakage, > and in light of what you said three years ago, it appears to be a > no-brainer to use PRIVATE TLL for the PLplot static libraries at least > in the Unix case. So assuming that for the PLplot build system I > follow up and prove that PRIVATE TLL works for both the shared and > static library cases on Unix, would you also recommend PLplot move to > PRIVATE TLL for both the shared and static library cases on Windows? > For all the target_...() commands, my recommendation is to make things PRIVATE by default and only use PUBLIC or INTERFACE if the relationship genuinely requires the thing in question to be applied to whatever links to that target. The platform is not a factor unless the API is different on different platforms. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> Consulting services (CMake, C++, build/release processes): https://crascit.com/services -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
Re: [CMake] Providing multiple different MAJOR API versions with write_basic_package_version_file
On Mon, Nov 4, 2019 at 10:54 PM Philip Van Hoof wrote: > Hello, > > After Craig's very interesting presentation at CppCon 2019* I learned a > bunch of new things which I of course immediately wanted to try out**. > > I read about the write_basic_package_version_file which is in > CMakePackageConfigHelpers. Craig also mentioned in the presentation > that you can have a so called API-version in the target's name. And > that for example Qt does this (Qt5Core, which has the MAJOR number 5 in > its target name). > > For my target name I prefer to have the API version after a dash, like > how GLib and DBus packages do it: libglib-2.0.so.0.6200.1 on current > Ubuntu, for example in /usr/lib/x86_64-linux-gnu. > Understand that from CMake's point of view, the library name is then glib-2.0 and the fact that it contains numbers that look like a version of some kind is completely irrelevant (to CMake). You could just as well have called it glib-specialsauce. Putting an API version into the library name is *changing* the library name to something else. This is particularly inconvenient for projects using find_package() to find your library, since they have to specify the exact API version now because you've included it in the library name. glib-2.0 is a completely different library to glib-2.1, for example. It might be more precise, but it is less convenient to consume. You could potentially remove that inconvenience by naming the config package file glibConfig.cmake instead of glib-2.0Config.cmake, then place it under an API-versioned directory that find_package() would search in, but that would seem to remove the very advantage you are trying to gain by putting the API version in the library name. The consuming project would effectively be able to ignore the API version if you did this. > > I wonder what that means for the property of > write_basic_package_version_file. In the autotools and meson world, the > usage of pkg-config files seems to indicate that the same filename > naming scheme applies to the .pc file: > > /usr/lib/x86_64-linux-gnu/pkgconfig/glib-2.0.pc > > This allows me to distinguish between older MAJOR API versions of GLib > and newer MAJOR API versions of it, using FindPkgConfig*** > > Supposedly something similar is possible with find_package's .cmake > files as installed by write_basic_package_version_file? > As above, you are creating an entirely different library by putting the API version in its base name. So your call to find_package() would be looking for that API-specific name and your package version file would have to match that expected name too. > > How do I provide a PackageNameConfigVersion.cmake for major version 1.0 > and 2.0 (the equivalent of PackageName-1.0.pc and PackageName-2.0.pc in > the pkgconfig directory)? > Since from CMake's perspective they are two completely different libraries, you'd end up with PackageName-1.0ConfigVersion.cmake and PackageName-2.0ConfigVersion.cmake as the file names. > > Kind regards, > > Philip > > * https://www.youtube.com/watch?v=m0DwB4OvDXk > ** > https://github.com/pvanhoof/dir-examples/commit/523cab5edaff99acba037218d5b95227cb2487a9 > *** https://cmake.org/cmake/help/v3.15/module/FindPkgConfig.html I've debated whether to express my own opinion on this, but in this case I'll risk it. I personally find that putting an API version in the name of the library itself to be an annoyance. I'm typically interested in the ABI versioning, and I take on the responsibility of understanding how that maps to the API. If semantic versioning is being followed for the ABI versioning, then this mapping is typically trivial. To me, any gains from making the API version explicit in the library name are less significant than the negative impact on the ease of consuming that library and the added "scare factor" of an overly complicated versioning system. Versioning is already complex enough for most users, if we can avoid making it more so, then users will likely appreciate that. It may be instructive to note that there were changes in CMake 3.14 to support Qt being found without the API version being specified as part of the package name (i.e. as find_package(Qt)). See policy CMP0084 <https://cmake.org/cmake/help/latest/policy/CMP0084.html> for some brief background. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> Consulting services (CMake, C++, build/release processes): https://crascit.com/services -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
Re: [CMake] modifying cmake_build_type cflags per target
On Tue, Nov 19, 2019 at 10:36 PM Eric Doenges wrote:
> Am 19.11.19 um 12:09 schrieb Stéphane Ancelot:
>
> Hi,
>
> I have a particular target (using swig / jni) that must not have -O3
> -NDEBUG flags from Relase build type
>
> How can I overload this target flags ?
>
> Since CMAKE__FLAGS_RELEASE does not map to a user-visible target
> property, you cannot override it directly (anything added to the
> COMPILE_FLAGS property is appended to the command line and does not replace
> any of the compiler flags CMake sets by itself). However, you can redefine
> this variable before you create your special target(s), and then restore it
> so that other targets are not affected:
>
> set(_CMAKE_CXX_FLAGS_RELEASE_SAVE ${CMAKE_CXX_FLAGS_RELEASE})
> set(CMAKE_CXX_FLAGS_RELEASE)
> < add your target(s) here >
> set(CMAKE_CXX_FLAGS_RELEASE ${_CMAKE_CXX_FLAGS_RELEASE_SAVE})
>
> This assumes your target is C++; if it is C, simply replace the _CXX_ with
> _C_.
>
Actually, no, that's not how it works. This is actually a great example of
why projects shouldn't generally try to avoid manipulating CMAKE_CXX_FLAGS
and should instead prefer to modify target or directory properties instead
(not possible here for the original problem, but worth highlighting
nonetheless). The (often surprising) behavior at play in the proposed
example above is that it is not the value of the CMAKE_CXX_FLAGS_RELEASE
variable at the time the target is created that matters, it's the
variable's value *at the end of the directory scope*. You can change the
variable's value as much as you like along the way before or after creating
targets, but only the final value at the end of the scope will actually be
used in the build command lines for targets created in that directory
scope. This is rarely what developers expect, but that's how it works, for
better or worse. When you start adding in calls to add_subdirectory(), it
can get really confusing what value is getting used where, so take great
care if your project really must modify these variables.
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
--
Powered by kitware.com/cmake
Kitware offers various services to support the CMake community. For more
information on each offering, please visit https://cmake.org/services
Visit other Kitware open-source projects at https://www.kitware.com/platforms
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
This mailing list is deprecated in favor of https://discourse.cmake.org
Re: [CMake] graphviz missing dependencies when target spans multiple subfolders
On Sat, Oct 26, 2019 at 9:11 AM Rich von Lehe wrote:
> I am using CMake 3.15.1. Having found out about some of the changes with
> 3.13, I've started to take advantage of using 'add_subdirectory()' in
> certain cases when a module is large and spans multiple source folders.
>
> For instance:
>
> ModuleA/CMakeLists.txt:
>
> add_library(moduleA STATIC "")
>
> add_subdirectory(sub1)
> add_subdirectory(sub2)
> --
>
> sub1/CMakeLists.txt
> --
> target_include_directories(moduleA PUBLIC .)
> target_sources(moduleA
>PRIVATE
> src1.cpp
> src2.cpp
> )
>
> target_link_libraries(moduleA
> PRIVATE
> Qt5::Widgets
> Qt5::Qml
> moduleB
> )
>
> sub2/CMakeLists.txt
> --
> target_include_directories(moduleA PUBLIC .)
> target_sources(moduleA
> PRIVATE
> src1.cpp
> src2.cpp
> )
>
> target_link_libraries(moduleA
> PRIVATE
> Qt5::Quick
> moduleC
> )
> ---
>
> I run cmake --graphviz=project.dot .
>
> From this, two of the files that comes out are project.dot.moduleA and
> project.dot.moduleA.dependers.
>
> The former is only this:
> digraph "GG" {
> node [
> fontsize = "12"
> ];
> "node190" [ label="moduleA" shape="diamond"];
> }
>
> There is no mention of the Qt5 or other module dependencies.
>
>
> Other modules with dependencies but without the hierarchy introduced with
> add_subdirectory() seem to be just fine and include their respective
> dependencies in their project.dot.moduleX files.
>
> Is this a bug or am I misusing add_subdirectory() here? With the
> exception of the graphviz output, everything builds and runs as expected
> with my setup.
>
The structure of your project looks fine, it's probably a bug in the
graphviz handling. There has been a bit of activity around improving that
recently, so it's possible that it has either been broken recently or has
been fixed on master already. Can you please try a few earlier CMake
versions and see if the problem has always been there? If it looks like a
recently introduced regression, please also try a nightly build of the
latest master (or build CMake from sources yourself if you're happy to do
that). If the bug is still there on master, I suggest you file a bug report.
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
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
Re: [CMake] Is there a "package" equivalent for CMAKE_SKIP_INSTALL_ALL_DEPENDENCY
On Sat, Oct 26, 2019 at 10:39 AM Scott Bloom wrote: > I’m looking for an equivalent to CMAKE_SKIP_INSTALL_ALL_DEPENDENCY for > packages, so when I do a make package, it doesn’t build all first. > > > > Does one exist? > You can just invoke cpack directly instead of doing a make package. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> 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
Re: [CMake] using `install()` with EXPORT and COMPONENT
On Mon, Sep 30, 2019 at 4:09 AM Stefan Seefeld wrote:
> Hi Craig,
>
> thanks for the detailed explanation !
> On 2019-09-29 5:13 a.m., Craig Scott wrote:
>
>
> If all of your headers should be installed to a single directory, then you
> can list the headers in the target's PUBLIC_HEADER or PRIVATE_HEADER target
> property, then make sure you add those destinations in the install(TARGETS
> ...) command. For example:
>
> include(GNUInstallDirs)
> install(TARGETS myLib
> EXPORT SomeProj_Targets
> RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
> COMPONENT SomeProj_Runtime
> LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
> COMPONENT SomeProj_Runtime
> NAMELINK_COMPONENT SomeProj_Development # Requires CMake 3.12
> ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
> COMPONENT SomeProj_Development
> PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
> COMPONENT SomeProj_Development
> INCLUDES DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
> )
>
> I hadn't noticed one can have multiple 'COMPONENT' sections in a single
> `install` call. The CMake documentation could be a bit more clear about
> that.
>
>
> If you need to install headers into more than one directory (i.e. your
> headers have some sort of directory hierarchy), then the above doesn't work
> because it flattens all of the headers into a single location. Instead, you
> have to use install(FILES ...) to install the headers directly for such
> cases. Also, the target_include_directories() command has nothing to do
> with what header files get installed. Rather, it only controls the header
> search paths attached to a target.
>
> Right, true.
>
> FYI, part of my CppCon talk "Deep CMake For Library Authors" from a couple
> of weeks ago has a fair amount of overlap with this topic (specifically
> install components and destinations). I'm waiting for the YouTube clip to
> be made available and then I'll be posting a blog article on my website
> with links and the slides. When it goes up, you'll be able to find it at
> https://crascit.com (hopefully sometime this week, but depends how
> quickly the production people get the video done).
>
> Great, looking forward to reading the slides.
>
The CppCon talk and slides are now available. You can find them here:
https://crascit.com/2019/10/16/cppcon-2019-deep-cmake-for-library-authors/
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
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
Re: [CMake] cmake end user vs. developer rpath handling
On Wed, Oct 9, 2019 at 5:24 PM Zakrzewski, Jakub <
jakub.zakrzew...@scheer-group.com> wrote:
>
>
> From: CMake on behalf of DIXON, MARK C. <
> mark.c.di...@durham.ac.uk>
> Sent: 08 October 2019 17:25
> To: cmake@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 <https://crascit.com/professional-cmake/>
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
Re: [CMake] DEPENDS parameter of add_custom_target
On Mon, Oct 7, 2019 at 11:21 PM Setzer Sebastian (CM-CI2/ECS2) < sebastian.set...@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@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 > <mailto:cmake@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 <https://crascit.com/professional-cmake/> 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
Re: [CMake] DEPENDS parameter of add_custom_target
On Mon, Oct 7, 2019 at 9:32 PM Setzer Sebastian (CM-CI2/ECS2) via CMake < cmake@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 <https://crascit.com/professional-cmake/> 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
Re: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS
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 <https://crascit.com/professional-cmake/>
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
Re: [CMake] Use interface libraries for providing compile options and definitions
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 <https://gitlab.kitware.com/cmake/cmake/issues> 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 <https://crascit.com/professional-cmake/> 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
Re: [CMake] using `install()` with EXPORT and COMPONENT
On Sun, Sep 29, 2019 at 6:38 AM Stefan Seefeld wrote:
> Hello,
>
> I'm working on a library project that will be packaged in multiple
> components. A "runtime" component will contain the (shared) library, an a
> "dev" component the associated headers (and perhaps other development-only
> artefacts).
>
> I have successfully used the `install()` command to install these two sets
> of artefacts, i.e. calling `install(... COMPONENT runtime)`, as well as
> `install(... COMPONENT dev)`.
>
> However, I'm now looking into calling `install(TARGETS ... EXPORT ...)`.
> The documentation explains how the list of installed headerfiles can
> actually be inferred from the target itself (if the
> target_include_directories have been appropriately set). However, I can't
> call that function more than once on the same target, and thus I seem to
> have no way to split the installation into multiple components.
>
> Does anyone know what I'm missing ? What is the suggested way to package a
> project into the usual "runtime" and "dev" components ?
>
If all of your headers should be installed to a single directory, then you
can list the headers in the target's PUBLIC_HEADER or PRIVATE_HEADER target
property, then make sure you add those destinations in the install(TARGETS
...) command. For example:
include(GNUInstallDirs)
install(TARGETS myLib
EXPORT SomeProj_Targets
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
COMPONENT SomeProj_Runtime
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
COMPONENT SomeProj_Runtime
NAMELINK_COMPONENT SomeProj_Development # Requires CMake 3.12
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
COMPONENT SomeProj_Development
PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
COMPONENT SomeProj_Development
INCLUDES DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
)
If you need to install headers into more than one directory (i.e. your
headers have some sort of directory hierarchy), then the above doesn't work
because it flattens all of the headers into a single location. Instead, you
have to use install(FILES ...) to install the headers directly for such
cases. Also, the target_include_directories() command has nothing to do
with what header files get installed. Rather, it only controls the header
search paths attached to a target.
FYI, part of my CppCon talk "Deep CMake For Library Authors" from a couple
of weeks ago has a fair amount of overlap with this topic (specifically
install components and destinations). I'm waiting for the YouTube clip to
be made available and then I'll be posting a blog article on my website
with links and the slides. When it goes up, you'll be able to find it at
https://crascit.com (hopefully sometime this week, but depends how quickly
the production people get the video done).
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
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
Re: [CMake] Ninja generator emits order-only dependencies for custom commands
On Sat, Sep 28, 2019 at 1:31 PM melak47 wrote: > I'm using add_custom_command with the Ninja generator on Windows to > invoke mc.exe on an .mc file, > to generate an .rc file, to create a resource DLL. > The full example is here: > https://gist.github.com/melak47/f7d83046c6d57b338d633468d078f5b1 > > The problem is, changing the .mc file and rebuilding only causes mc.exe > to rerun, > anything depending on the generated .rc file is not rebuilt. > I think this happens because cmake generates some order-only > dependencies for the generated files. > > Some of the relevant build statements that are generated: > > > # > > = > # Object build statements for MODULE_LIBRARY target example > > > # > # Order-only phony target for example > > build cmake_object_order_depends_target_example: phony || example.hpp > example.rc example_MSG1.bin > > build CMakeFiles\example.dir\example.rc.res: RC_COMPILER__example > D$:\repro\build\example.rc || cmake_object_order_depends_target_example > DEFINES = -Dexample_EXPORTS > DEP_FILE = CMakeFiles\example.dir\example.rc.res.d > FLAGS = -DWIN32 -D_DEBUG > OBJECT_DIR = CMakeFiles\example.dir > OBJECT_FILE_DIR = CMakeFiles\example.dir > TARGET_COMPILE_PDB = CMakeFiles\example.dir\ > TARGET_PDB = example.pdb > > > # > > = > # Link build statements for MODULE_LIBRARY target example > > > # > # Link the shared module example.dll > > build example.dll: CXX_MODULE_LIBRARY_LINKER__example > CMakeFiles\example.dir\example.rc.res > LANGUAGE_COMPILE_FLAGS = /DWIN32 /D_WINDOWS /GR /EHsc /Zi /Ob0 /Od > /RTC1 -MDd > LINK_FLAGS = /machine:x64 /debug /INCREMENTAL /noentry > LINK_LIBRARIES = kernel32.lib user32.lib gdi32.lib winspool.lib > shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib > OBJECT_DIR = CMakeFiles\example.dir > POST_BUILD = cd . > PRE_LINK = cd . > TARGET_COMPILE_PDB = CMakeFiles\example.dir\ > TARGET_FILE = example.dll > TARGET_IMPLIB = example.lib > TARGET_PDB = example.pdb > > > # > # Custom command for example.rc > > build example.rc example.hpp example_MSG1.bin: CUSTOM_COMMAND > ..\example.mc > COMMAND = cmd.exe /C "cd /D D:\repro\build && "C:\Program Files > (x86)\Windows Kits\10\bin\10.0.18362.0\x64\mc.exe" -b -e hpp -h > D:/repro/build -r D:/repro/build D:/repro/example.mc" > DESC = Generating example.rc, example.hpp, example_MSG1.bin > restat = 1 > > > # > # Assume dependencies for generated source file. > > build D$:\repro\build\example.rc: CUSTOM_COMMAND || > cmake_object_order_depends_target_example > COMMAND = cmd.exe /c > restat = 1 > > > As you can see, CMakeFiles\example.dir\example.rc.res depends on > D$:\repro\build\example.rc, > which depends on the actual example.rc through > cmake_object_order_depends_target_example as > an **order-only** dependency. > If I read the ninja manual correctly, this means changes to example.rc > will by design not cause depndees to be rebuilt. > > If instead of an empty CUSTOM_COMMAND, cmake emitted a phony like: > > build D$:\repro\build\example.rc: phony example.rc > > example.rc.res and example.dll would be properly rebuilt. > (Also, a phony does not appear in the build log, unlike the empty > CUSTOM_COMMAND which just shows up as 'cmd /c') > > Is this a bug, or is there some intent behind emitting a CUSTOM_COMMAND > here? > This seems like a bug to me, please add it to gitlab as a new issue here: https://gitlab.kitware.com/cmake/cmake/issues Please ensure you also record what version of CMake you are using. If you can test with some different CMake versions to confirm whether it is a long-standing issue or a regression in a more recent version, that would also be very helpful. I believe there have been a few changes relating to RC handling in the last few releases, so can't rule out a regression. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> 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 offe
Re: [CMake] printing CMAKE_CXX_FLAGS_* based on build type
On Sat, Sep 28, 2019 at 8:15 AM Zdenko Podobny wrote:
> Yes, build type is known (e.g value of ${CMAKE_BUILD_TYPE} is shown in
> output). I use command like this:
> cmake .. -G Ninja -DCMAKE_INSTALL_PREFIX=%INSTALL_DIR%
> -DCMAKE_PREFIX_PATH=%INSTALL_DIR% -DCMAKE_BUILD_TYPE=Release
>
>
> Zdenko
>
>
> pi 27. 9. 2019 o 23:54 fdk17 napísal(a):
>
>> Are you using a generator that uses CMAKE_BUILD_TYPE and has it set to a
>> known value? Build type doesn’t have to be set and multi-config generators
>> don’t use it.
>>
>> On Fri, Sep 27, 2019, at 4:18 PM, Zdenko Podobny wrote:
>>
>> Hello,
>>
>> I try to print CMAKE_CXX_FLAGS_DEBUG/CMAKE_CXX_FLAGS_RELEASE as one line
>> statement but is does not work for me:
>>
>> message( STATUS "CXX compiler ${CMAKE_BUILD_TYPE} build options:
>> ${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}}")
>>
>>
CMake variable names are case-sensitive. The value of CMAKE_BUILD_TYPE is
likely not all uppercase, so ${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}} will
almost certainly end up naming a variable that isn't defined.
Also, as fdk17 has already mentioned, CMAKE_BUILD_TYPE isn't always
defined. For multi-configuration generators (e.g. Visual Studio, Xcode), it
typically won't be defined and if it was, it would be meaningless. If you
have logic switching on CMAKE_BUILD_TYPE, it is usually a sign you are
trying to do something you shouldn't (or that you explicitly don't support
multi-config generators).
>
>> Produce empy result, but
>> message( STATUS "CXX compiler Release build options:
>> ${CMAKE_CXX_FLAGS_RELEASE}")
>> works as expected.
>> Is it possible to do it in one line or I have to use if/elseif ?
>>
>> Zdenko
>>
>>
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
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
Re: [CMake] ?==?utf-8?q? Debug logging of items
You may want to take a look at the BUILDSYSTEM_TARGETS
<https://cmake.org/cmake/help/latest/prop_dir/BUILDSYSTEM_TARGETS.html>
directory property. It might not be quite what you're looking for, but it
might be close enough. I'm not aware of any way to get a list of all
defined properties on a given target though.
On Mon, Sep 23, 2019 at 12:47 AM Cornelis Bockemühl
wrote:
> Hi Eric,
>
> Thanks for the hint regarding dumping variables: That's good to know!
>
> However, I was learning that working with CMake is in may ways a question
> of adopting some "good practice", but it is not really being enforced by
> the language. One of the things that are for me part of this good practice
> would be to deal with targets and their dependencies, and properties. Which
> means a certain degree of modularity in the sense that you can easily plug
> projects together by just referring to targets, like by calling
> find_package().
>
> But again: You will never easily know what a package is actually giving
> you - without investing hours and days of code reading - and maybe not even
> then!
>
> But calling some "dump_targets" function after "find_package" (or also
> before and after - for comparison) would give you a chance to know the
> effect of endless "code deserts" with one line of code.
>
> And because this is so fundamental in my eyes, I still almost assume that
> also for targets and properties there must be some function available -
> which I simply have not found yet!??
>
> Or else I would consider this an urgent feature request!
>
> Best regards,
> Cornelis
>
>
> Am Freitag, September 20, 2019 15:07 CEST, Eric Doenges
> schrieb:
>
>
>
>
> I don't know about the targets, but you can get all variables currently
> defined for a directory by reading the VARIABLES property, e.g.
>
> get_property(_variables DIRECTORY "${CMAKE_SOURCE_DIR}" PROPERTY VARIABLES)
>
> I use this to dump the variables into a file so I can see with which
> variable settings my build directory was configured with.
>
> With kind regards,
> Eric
> Am 20.09.19 um 14:49 schrieb Cornelis Bockemühl:
>
> Right now I am fighting my way through large amounts of CMake code
> (actually working on a ParaView custom application with many own plugins,
> views, domains, property widgets etc. etc.), and it is sometimes really not
> easy not to lose track completely! Sometimes I am happy to be back into
> complex C++ programming - because I see much more logic in the entire
> thing. And it is of course no news that CMake code is not famous for being
> easy to debug.
>
> Anyway, I am dreaming of some "simple" features that would sometimes help
> a lot, and it is all about "dumping" some kind of data. Actually this is
> for me often also the favorite way to debug C++ code: just print out the
> values of variables, arrays, etc. - e.g. if setting a breakpoint in the
> debugger is difficult because you are interested only in the 928773th
> occurrence of a certain piece of code (without even knowing that number...).
>
> Accordingly in CMake code I am working a lot with the message() function -
> but within that code the problem is often that you do not even know which
> variables would be available at all!
>
> Thus functions like would be really great to have:
>
> “give me a list of all currently known targets”
> “give me a list of all properties of a target”
> “give me a list of all currently defined variables”
> etc.
>
> What I do not know is: Are this things that already exist - in which case
> I would be happy if somebody could tell me how to find them! -, or are
> these functions rather "feature requests"?
>
> In fact I can hardly believe that I am the first with such kind of dreams,
> so my hope is still that they already exist somewhere...
>
>
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
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
Re: [CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES ...)
On Fri, Sep 13, 2019 at 8:24 AM Theodore Hall wrote: > Greetings, > > set_target_properties(target PROPERTIES > IMPORTED_LOCATION location > IMPORTED_IMPLIB implib > INTERFACE_INCLUDE_DIRECTORIES directory+ > ) > > Is there a way to assign more than one directory to > INTERFACE_INCLUDE_DIRECTORIES ? The property name is plural, but every > attempt I've made to specify more than one directory has failed. CMake > complains that either: I've passed the wrong number of arguments; or > concatenates all of them into one path which of course doesn't exist. > > I've found a work-around using > > target_include_directories (target > INTERFACE directory1 > INTERFACE directory2 > ) > > It just seems odd that a property with a plural name accepts only a > singular value. I feel like I'm missing something. I've tried wrapping > multiple directories in various kinds of brackets and quotes and separating > them with ; or , instead of whitespace. (This is Windows, so : isn't a > path separator; the system PATH variable uses ; as the separator.) > OPTION A: Put quotes around a semi-colon separated string if using set_target_properties(): set_target_properties(target PROPERTIES IMPORTED_LOCATION location IMPORTED_IMPLIB implib INTERFACE_INCLUDE_DIRECTORIES "directory1;directory2" ) OPTION B: List multiple directories after just one INTERFACE keyword if using target_include_directories(): target_include_directories (target INTERFACE directory1 directory2 ) Either option should work for all platforms, but note that option A will overwrite any previous contents of INTERFACE_INCLUDED_DIRECTORIES whereas option B will append to any previous contents. For that reason, I'd generally recommend option B. > -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> 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
Re: [CMake] The connection to cmake-server was terminated unexpectedly [cms-client] cmake-server exited with status null (SIGSEGV)
On Thu, Sep 5, 2019 at 7:56 AM Christopher Dawes <
christopher.da...@eftlab.com> wrote:
> Awesome thank you so much! So i’ve upgraded to 3.15.3 and it’s told me
> perfectly my issue. So I have an override script (FindLibXml2.cmake):
>
> *** START CODE ***
> # FindLibXml2.cmake
> #
> # A wrapper around CMake's FindLibXml2 which provides an imported target.
>
> # Find LibXml2 using the built-in module
> set(_cmake_module_path "${CMAKE_MODULE_PATH}")
> set(CMAKE_MODULE_PATH)
> include(FindLibXml2)
> set(CMAKE_MODULE_PATH "${_cmake_module_path}")
>
> if(LibXml2_FOUND AND NOT TARGET LibXml2::LibXml2)
> add_library(LibXml2::LibXml2 INTERFACE IMPORTED)
> set_target_properties(LibXml2::LibXml2 PROPERTIES
> INTERFACE_LINK_LIBRARIES "${LIBXML2_LIBRARIES}"
> INTERFACE_INCLUDE_DIRECTORIES "${LIBXML2_INCLUDE_DIR}")
> else()
> #https://github.com/Homebrew/homebrew-core/issues/6186
> if(APPLE)
> get_target_property(id LibXml2::LibXml2 INTERFACE_INCLUDE_DIRECTORIES)
> list(REMOVE_ITEM id "/usr/include/libxml2")
> set_target_properties(LibXml2::LibXml2 PROPERTIES
> INTERFACE_INCLUDE_DIRECTORIES "${id}")
> endif()
> endif()
>
> *** END CODE ***
>
> So the issue was:
> set(CMAKE_MODULE_PATH)
>
> doesn’t work in cmake-server; also unset(CMAKE_MODULE_PATH) didn’t work
> either, when i do:
>
> set(CMAKE_MODULE_PATH “/nonexistent”)
>
> it all comes good; for some reason i think unset isn’t quite happy on
> cmake-server.
>
Check that you don't also have a CMAKE_MODULE_PATH cache variable as well.
If you unset the non-cache variable, it will effectively unmask the cache
variable of the same name.
> Many thanks again for your quick response!
>
> *Christopher Dawes*
> *Principal Architect, EFTLab*
>
> *M:* +44 (0)7899 842 759
> *E:* christopher.da...@eftlab.com
> *A:* 109 Brighton Road, Sandgate, QLD 4017
>
> *IMPORTANT NOTICE*
> This message contains confidential information and is intended only for
> the addressee(s). E-mail transmission cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses. EFTlab Pty Ltd cannot accept
> liability for any errors or omissions in the contents of this message,
> which may arise as a result of e-mail transmission. Please note that EFTlab
> Pty Ltd may monitor, analyse and archive email traffic, data and the
> content of email for the purposes of security, legal compliance and staff
> training. If you have received this email in error please notify us at
> supp...@eftlab.com.au.
>
> On 4 Sep 2019, at 19:39, Kyle Edwards via CMake wrote:
>
> On Wed, 2019-09-04 at 14:12 -0400, fdk17 wrote:
>
> https://github.com/microsoft/vscode-cmake-tools/issues/752 states
> that it ran out of stack and the log shows what looks like to be
> involved with a recursive loop in some CMakeLists.txt. A call depth
> of 27491 seems a bit excessive.
>
> After the second call to FindPackage it just seems to be doing the
> same thing over and over again.
> I'd think a newer version of CMake would complain about too much
> recursion in the project files.
>
>
> Indeed, this was added in 3.14:
>
> https://cmake.org/cmake/help/v3.14/variable/CMAKE_MAXIMUM_RECURSION_DEP
> TH.html
> Kyle
> --
>
> 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
>
>
> --
>
> 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
>
&
Re: [CMake] Excluding targets from install set
On Tue, Jul 23, 2019 at 7:04 PM Gordon Koefner
wrote:
> Hi all!
>
> We have been migrating our buildsystem to CMake and are trying to use
> the `install` command to deploy different parts of the software.
> However `make install` also installs artifacts from our dependencies,
> internal as well as 3rd party, that are unnecessary/unwanted.
>
> Is there a native way to exclude certain subdirectories or build targets
> from the install set? The only solution I could think of is to manually
> add an option, e.g.:
>
> option(${TARGET_NAME}_INSTALL on "") # on by default
> if(${TARGET_NAME}_INSTALL)
> install(...)
> endif()
>
> Maybe the culprit is also that we are using find_path and
> add_subdirectory to add any internal dependencies we have to the build
> tree - I am starting to think that this is a mistake.
>
> I have read about ExternalProject - but I am unsure whether this is the
> correct way to go about it but it does allow modification of another build.
>
> How do you guys solve this issue, how can I define which dependencies I
> want installed?
>
> I really want to avoid writing a shellscript to filter out any unwanted
> stuff.
>
A bit late, but clearing my inbox and found this one still unanswered. ;) I
typically handle this situation by defining install components for my own
part of the build (i.e. including COMPONENT options with my install()
commands). Then when I want to make packages, I populate
CPACK_COMPONENTS_ALL with just those components I want included. All
dependencies are part of the build (using FetchContent), it's just that I
don't add their install components to my list so they are left out. I don't
do a bare "make install", I always create packages, so this works for me.
If you did want to do an install directly, you could use the new "cmake
--install" functionality added in CMake 3.15 which supports specifying the
component to install. The end of the documentation page for the install()
command also shows another way to install components selectively (under the
heading Generated Installation Script).
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] escape double quote in generated file
On Sat, Aug 31, 2019 at 12:36 AM Eugene Karpov wrote:
> Hello all,
>
> I'm working on a cross platform project. On Ubuntu I would like to save
> all the compiler options, definitions and other complier related stuff to a
> generated file to use it later for precompiled header generation.
> My issue is that I have to specify a macro that contain double quotes for
> g++ compiler visibility attribute. When I generate a file with double
> quotes they are not escaped. I also tried to use `string(replace "\""
> "\\\""...)` without effect.
> I've made simple two files project of a shared library to show the issue.
> It has only target compile definitions for simplicity.
>
> - CMakeLists.txt --
> cmake_minimum_required(VERSION 3.14)
> set(target test)
> project(${target})
> if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
> set(API_IMPORT_MACRO "__attribute__((visibility(\"default\")))")
> set(API_EXPORT_MACRO "__attribute__((visibility(\"default\")))")
> else()
> set(API_IMPORT_MACRO "__declspec(dllimport)")
> set(API_EXPORT_MACRO "__declspec(dllexport)")
> endif()
> function(export_all_flags _target _filename)
> set(_compile_definitions
> "$")
> set(_compile_definitions
> "$<$:-D$\n>")
> file(GENERATE OUTPUT "${_filename}" CONTENT "${_compile_definitions}")
> endfunction()
> add_library(${target} SHARED test.cpp)
> target_compile_definitions(${target}
> PRIVATE API=${API_EXPORT_MACRO}
> INTERFACE API=${API_IMPORT_MACRO})
> export_all_flags(${target} ${CMAKE_BINARY_DIR}/flags.txt)
> - CMakeLists.txt --
> - test.cpp --
> void API test() {}
> - test.cpp --
>
> The result file "flags.txt" is following:
> -DAPI=__attribute__((visibility("default")))
>
> I would like any solution to make the result as:
> -DAPI=__attribute__((visibility(\"default\")))
>
Are you free to modify the headers where the API_IMPORT/API_EXPORT symbols
are used? If so, then it is far easier to delegate the definition of such a
symbol to a separate header file rather than try to define it directly on
the compiler command line. The GenerateExportHeader
<https://cmake.org/cmake/help/latest/module/GenerateExportHeader.html>
module provides a convenient way to create such a header and also set the
relevant details in your CMake target to do the right thing when building
and when consuming the library. I'd expect it to be suitable for a
precompiled header scenario too.
And shameless plug, if you're interested in this area (symbol visibility),
part of my upcoming CppCon talk <https://sched.co/SfnH> in a few weeks will
cover exactly this topic. ;)
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] using fetch_content imported modules and not system one
On Thu, Aug 29, 2019 at 11:14 PM Stéphane Ancelot
wrote:
> hi,
>
> i used fetch_content to download bullet library , but I cant use it.
>
> FetchContent_Declare(
> bullet
> GIT_REPOSITORY https://github.com/bulletphysics/bullet3.git
> GIT_TAG2.88
>
> )
>
> FetchContent_GetProperties(bullet)
> if(NOT bullet_POPULATED)
> FetchContent_Populate(bullet)
> add_subdirectory(${bullet_SOURCE_DIR} ${bullet_BINARY_DIR})
> endif()
>
> linking using bullet does not permit to find any include or lib file
>
Your FetchContent usage looks fine. I had a quick scan through the bullet
project and it uses very old CMake patterns. In particular, it doesn't use
any of the target-centered commands like target_include_directories(), etc.
This means it doesn't define PUBLIC or INTERFACE properties on targets,
which is why when you try to link to the bullet targets and include its
headers, they aren't being found. Nothing is telling consumers of those
libraries where to look.
Ideally, the bullet project would update to more modern CMake practices,
but that's not always a priority for projects that others manage. If you
need to get this working for your build, you will have to manually add the
missing header search paths and inter-library dependencies in your own
project. You can still call target_include_directories() on the bullet
targets from outside of the bullet source tree. You would do this
immediately after the add_subdirectory() call, something like the following
structure:
if(NOT bullet_POPULATED)
FetchContent_Populate(bullet)
add_subdirectory(${bullet_SOURCE_DIR} ${bullet_BINARY_DIR}
target_include_directories(Bullet3Common INTERFACE
${bullet_SOURCE_DIR}/src
${bullet_SOURCE_DIR}/src/Bullet3Common
... more as you work out what is needed
)
endif()
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] import objects to CMake
On Tue, Jul 23, 2019 at 10:27 PM hex wrote: > hello community, > > Following an example on the usage of IMPORTED_OBJECTS from the book > "Professional CMake" > I'm happy to accept corrections and suggestions for the book at the following link (it's a more appropriate channel than here on this list): https://crascit.com/contact/ > I receive the following error: > > *Error evaluating generator expression:* > > *$* > > * Expression did not evaluate to a known generator expression* > > > I wonder if there is a mistake in the code snippet? I was able to make it > work using TARGET_OBJECTS instead of TARGET_SOURCES (CMake 3.15). > Yes it is an error, it should have been $. It will be corrected in the next update. Thanks. > this is the original CMakeLists.txt: > add_library(myObjLib OBJECT IMPORTED) > set_target_properties(myObjLib PROPERTIES >IMPORTED_OBJECTS /some/path/obj1.obj > /some/path/obj2.obj > ) > > add_executable(myExe $) > -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] FetchContent/ExternalProject and URL_HASH
On Mon, Jul 22, 2019 at 10:37 AM Dustyn Blasig wrote: > Thanks for the info, Craig. > > I'm not very familiar with the intricacies of network downloads. If the > download itself guarantees the file was transferred correctly and the > checksum is only be used to verify its authenticity, then we probably don't > need it as we're only downloading these artifacts from trusted internal > sources. However, if the checksums need to be used in some cases to verify > the download was actually received and is in one correct piece then pulling > the checksum file and basically failing if either is corrupted is fine for > our use case. Can we assume the former, that CMake (and the underlying > tools) will guarantee the file is downloaded successfully even in the event > of a CTRL-C interruption or other signals? > I don't think it is realistic to expect CMake or the underlying tools to still give you a successful file download if you interrupt it. ;) One of the things the file(DOWNLOAD) command uses the checksum for is to check if it can avoid having to download the file already exists. Without the checksum, if there is already a file at the destination, CMake can't tell if it is the right file and will download it again each time. Something I hadn't considered in my previous reply was if the file to be downloaded is very big, then it may still end up being more efficient to download the separate checksum file each time and read the big file's checksum from it to avoid re-downloading the big file if you've already got it from a previous run. Another reason you might want to explicitly specify the checksum rather than download a checksum file is that after you've done a configure once, you won't need to do any network communication to get it for subsequent runs because the checksum can be used to confirm you already have the right file. This allows you to run configure while connected to the network, then disconnect and work offline thereafter (handy if you're on a laptop and travelling!). Another use for the checksum file is to ensure you are receiving the file you expect from the source. This can help catch things like man-in-the-middle attacks or other malicious acts where the download is intercepted and some other file substituted. If you have a trustworthy connection to the source, this is less likely to be a concern for you, but I'll leave that to your own judgement. > > > On Sun, Jul 21, 2019 at 3:49 AM Craig Scott > wrote: > >> >> >> On Wed, Jul 17, 2019 at 12:59 PM Dustyn Blasig wrote: >> >>> Hi All, >>> >>> We are pulling some artifacts from Artifactory which provides a checksum >>> file along with the artifacts at .md5 or .sha256. If I do not >>> include URL_HASH, does CMake automatically check to see if such a checksum >>> file exists and use it's value for the hash check? Or is there a way to >>> provide a URL for the checksum file rather than having to do file(DOWNLOAD >>> ), file(STRING ), URL_HASH=? >>> >> >> The point of the checksum file is to verify the file downloaded. It >> doesn't make a whole lot of sense to then download another file to provide >> that checksum, you'd just be moving the problem along one level of >> indirection. The assumption is when you provide the URL to be downloaded, >> if you want to use a checksum then you should also be able to provide that >> along with the URL. When the URL is being constructed on-the-fly though, >> this isn't typically true. In that case, you can't typically provide a >> checksum that isn't itself downloaded and therefore needs to be verified >> itself. >> >> To more directly answer your question, CMake doesn't offer any feature to >> automatically download a checksum file (that I'm aware of). The file >> command expects that actual checksum, not a location for where to retrieve >> it from for the reasons mentioned above. >> > -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] FetchContent/ExternalProject and URL_HASH
On Wed, Jul 17, 2019 at 12:59 PM Dustyn Blasig wrote: > Hi All, > > We are pulling some artifacts from Artifactory which provides a checksum > file along with the artifacts at .md5 or .sha256. If I do not > include URL_HASH, does CMake automatically check to see if such a checksum > file exists and use it's value for the hash check? Or is there a way to > provide a URL for the checksum file rather than having to do file(DOWNLOAD > ), file(STRING ), URL_HASH=? > The point of the checksum file is to verify the file downloaded. It doesn't make a whole lot of sense to then download another file to provide that checksum, you'd just be moving the problem along one level of indirection. The assumption is when you provide the URL to be downloaded, if you want to use a checksum then you should also be able to provide that along with the URL. When the URL is being constructed on-the-fly though, this isn't typically true. In that case, you can't typically provide a checksum that isn't itself downloaded and therefore needs to be verified itself. To more directly answer your question, CMake doesn't offer any feature to automatically download a checksum file (that I'm aware of). The file command expects that actual checksum, not a location for where to retrieve it from for the reasons mentioned above. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with FetchContent instead of Git Submodules
On Fri, Jun 28, 2019 at 12:18 PM Dustyn Blasig wrote: > Hi All, > > I'm attempting to replace our use of git submodules with FetchContent > flows instead so we can pull pre-built packages if they already exist > instead of buildings locally. > > However, I need to support a flow similar to Git submodules where > developers can edit a submodule and then rebuild the enclosing project > incrementally. Things seem to work OK if I jump into the fetched source > directories and check out branches, etc. However, even if I move the > download and source/unpacked folders outside the build (binary) directory > and then delete the build directory, rerunning CMake will blast away the > unpacked source even if the last extraction was with the same checksummed > download. I need to ensure a "clean" won't delete someones work in a > submodule, which is one reason why Git makes it hard to uninit and remove > submodules. > > Is there a best practice for a flow like this that I can replicate? > (Background info: I'm the creator of the FetchContent module) If you want to be making changes to the sources, you should clone that repo manually and point the build at it rather than try to modify the one that the project downloads for you. You do this by setting the FETCHCONTENT_SOURCE_DIR_ cache variable to override where the build should find the sources. Here's the relevant part from the FetchContent documentation: FETCHCONTENT_SOURCE_DIR_If this is set, no download or update steps are performed for the specified content and the _SOURCE_DIR variable returned to the caller is pointed at this location. This gives developers a way to have a separate checkout of the content that they can modify freely without interference from the build. The build simply uses that existing source, but it still defines _BINARY_DIR to point inside its own build area. Developers are strongly encouraged to use this mechanism rather than editing the sources populated in the default location, as changes to sources in the default location can be lost when content population details are changed by the project. The thinking behind this is that the project will assume it is in control of the sources unless told otherwise. By setting the above cache variable, you are telling FetchContent that "I want to use my own sources instead of whatever you would normally use". Either FetchContent is in control or you are. I use this feature a LOT. Let's say you're working on a project where you need to do some refactoring that requires changes in the top level project and in some of its dependencies. I will have the top level project cloned. I will also have separate manually cloned repos for those dependencies that I need to modify. When I run CMake on my top level project, I use FETCHCONTENT_SOURCE_DIR_ to point the build at my local cloned repos. That makes the build use my local clones so I can modify the sources, change branches, etc. without fear of things being changed under my feet. When I'm done, I'll commit and push my changes in each of the local cloned repos, then I'll update the GIT_HASH details of those dependencies in my top level project. I delete the FETCHCONTENT_SOURCE_DIR_<...> variables from my CMake cache and re-run CMake (and build) to confirm that I've updated my dependency hashes correctly, then I commit and push my changes to the top level project. I use this strategy with project hierarchies with 40+ dependencies that can be up to maybe 10 levels deep. I can pull out any dependency used anywhere in the hierarchy and work with my own local cloned repo without having to care about where in the project hierarchy that dependency is usually populated. Being able to easily and selectively switch between the project-controlled FetchContent-provided source or my own local cloned repo(s) is critical to being able to do this efficiently. If you look at the CMake cache variables in ccmake or cmake-gui, you will also see all the source directory overrides grouped together because the variable names all start with FETCHCONTENT_SOURCE_DIR (this is why I named the cache variables FetchContent creates this way instead of putting the dependency name at the front of the cache variable name). So you can quickly see for which dependencies you are currently using a local cloned repo instead of what the project normally uses. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CM
Re: [CMake] Multiple exports for a target installation
On Tue, Jun 18, 2019 at 10:29 AM Shoaib Meenai wrote: > Thank you! > > > > When you say having an export set that the other exports then depend on, > do you mean the COMPONENT option of the install(EXPORT) signature, or > something else? (Sadly the project I’m working with is still on CMake > 3.4.3, whose documentation says something very different for the COMPONENT > option than the latest version, but I’ll cross that bridge when I get to > it.) > As far as components and export sets are concerned, the behavior isn't much different between CMake 3.4 and 3.14. Think of it like this: - The config file for a package (i.e. its Config.cmake file) may refer to one or more export sets. It can do this in a way that some or all of the export sets are optional, pulling them in if present, silently continuing if not. It depends on the way the project wants to define and use its export sets. For most projects, they will require all export sets they refer to to be present. The optional components of a find_package() call might map to optional export sets (just one example of how optional export sets might be used). - An export set defines targets. That set of targets can span across one or more components. The export set requires all of those components to be installed/present or it is considered ill-formed (or put another way, the installation is incomplete). The install(TARGETS ... EXPORT ...) command determines what targets are in which export set. The install(EXPORT ...) command defines what component the actual export file is part of (further discussion on this below). - A component can include targets, files and custom scripts to be invoked when installing that component from a build tree. Targets and files can technically be part of multiple components, but this would be relatively uncommon and may complicate the export picture. A component may depend on one or more other components, e.g. a Development component may require a Runtime component, such as Development headers requiring the Runtime shared library. If a project decides to split up its exports across multiple export sets, there can be dependencies between them. For example, a project might define export set Algo which has components Fast and Accurate, and export set Apps which has components Gui and CLI. The project's Config.cmake file requires the Algo export set to be present but the Apps export set is optional and only pulled in if present. In this scenario, one might have the Fast and Accurate components installed, but not the Gui or CLI components. The Algo export set represents the mandatory parts of the package that will always be needed. The Gui and CLI components might not be installed if, for example, someone just wants to build against the libraries provided by the Fast and Accurate components (i.e. they are writing their own apps rather than wanting to use the apps that are provided by the Gui and CLI components). What can be a bit confusing is that the exported file itself is also part of a component. That exported file might or might not need to be installed, depending on whether the project is being distributed as purely runtime components or whether other projects might be building against it and therefore expect headers, package config files, etc. The exported file (which is installed by install(EXPORT ...) ) is only needed for the latter, so it is usually part of a Development component or something similarly named (hopefully named something project-specific rather than just a generic "Development"!). The Config.cmake file is also part of a component, and may be part of the same component that the export file is in. The above is how I think about packages, export sets and components. You could have more complicated arrangements and have some overlap between export sets, but I'd generally try to avoid that if possible. It's simpler if you can structure things with clear and unambiguous dependencies without cycles or overlaps. It's already quite involved even without those things! HTH > > > *From: *Craig Scott > *Date: *Saturday, June 15, 2019 at 10:43 PM > *To: *Shoaib Meenai > *Cc: *"cmake@cmake.org" > *Subject: *Re: [CMake] Multiple exports for a target installation > > > > > > > > On Sat, Jun 15, 2019 at 9:03 PM Shoaib Meenai wrote: > > Is it possible to associate a target with multiple exports? For example, > if I'm building a project where I want to create multiple export sets, but > there's some overlap in targets between those sets. I tried passing > multiple EXPORT options to the install(TARGETS) signature but I just got an > error: install TARGETS given unknown argument "EXPORT". > > > Typically, you'd want your export sets to not be overlapping and to > contain no cyclic dependencies. If you have a t
[CMake] CMake now available to Linux users as a snap
Hi all. For those of you working on Linux, I'm pleased to announce that CMake is now available as a snap. This can be a great way to conveniently keep up with the latest CMake releases, even on Linux distributions that are no longer updating their own CMake packages. You can find a brief blog post about it here: https://crascit.com/2019/06/18/cmake-now-available-as-a-snap/ -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Why do executables link static libs that shared libs were built from?
On Sat, Jun 15, 2019 at 5:01 PM Paul Smith wrote:
> I have a situation where I create a number of static libraries, then I
> create a shared library from them, then I create an executable from the
> shared library.
>
> This seems straightforward, but I can't get it do work as I want. The
> behavior of STATIC -> SHARED for target property inheritance seems
> incorrect to me.
>
> I'm using CMake 3.14.5 on GNU/Linux for this test.
>
> I need the compile properties of the static library (include
> directories etc.) to be public for all users of the shared library as
> well. But obviously I don't want users of the shared library to also
> link the static library!! That defeats the whole purpose of the shared
> library.
>
> If I set up like this:
>
> $ touch foo.c bar.c
> $ echo 'int main() { return 0; }' > run.c
>
> then write my CMakeFiles.txt like this:
>
> cmake_minimum_required(VERSION 3.13)
> project(Test C)
>
> add_library(foo STATIC foo.c)
> target_include_directories(foo PUBLIC /tmp)
>
> add_library(bar SHARED bar.c)
> target_link_libraries(bar PUBLIC foo)
>
> add_executable(run run.c)
> target_link_libraries(run PUBLIC bar)
>
> Then, I DO get the -I/tmp forwarded up to run.c:
>
> cc -I/tmp -o CMakeFiles/run.dir/run.c.o -c run.c
> ^^
>
> But libfoo.a is ALSO added to my link line, which is really wrong!
>
> cc CMakeFiles/run.dir/run.c.o -o run -Wl,-rpath,. libbar.so libfoo.a
>
>
> On the other hand if I change the link of foo to be PRIVATE instead of
> PUBLIC:
>
> target_link_libraries(bar PRIVATE foo)
>
> then the link doesn't include libfoo.a, which is good, but I also don't
> have the -I/tmp when I compile run.c, which is wrong:
>
> cc -o CMakeFiles/run.dir/run.c.o -c run.c
> cc CMakeFiles/run.dir/run.c.o -o run -Wl,-rpath,. libbar.so
>
> Does this seem wrong to anyone else? Is there some trick to it?
>
The behaviour is correct according to what you are telling CMake to do. If
you use PUBLC in a target_link_libraries() call, you are saying that
anything that links to your shared library should also link to the static
library. PRIVATE would mean that the shared library uses the static library
internally but doesn't expose anything from the static library in the
shared library's interface or header files. If your executable needs to
know about the static library in any way (which means it includes any of
the static library's headers directly or any of the shared library's
headers pull them in), then the static library is no longer a private
dependency and has to be PUBLIC.
> Or do I have to resort to by-hand forwarding of build properties rather
> than relying on a straightforward target_link_libraries() line?
>
Look at your interfaces and header files carefully. Can you avoid referring
to anything from the static library in any of the shared library's public
headers (or any headers that those public headers pull in)? If so, then do
that and you can use target_link_libraries(bar PRIVATE foo). None of the
transitive properties of foo should be needed then either, so you'd have
nothing left to forward on. If you can't avoid it, then the static library
really is a public dependency and anything linking to bar should rightly
also be linking to foo.
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple exports for a target installation
On Sat, Jun 15, 2019 at 9:03 PM Shoaib Meenai wrote: > Is it possible to associate a target with multiple exports? For example, > if I'm building a project where I want to create multiple export sets, but > there's some overlap in targets between those sets. I tried passing > multiple EXPORT options to the install(TARGETS) signature but I just got an > error: install TARGETS given unknown argument "EXPORT". > Typically, you'd want your export sets to not be overlapping and to contain no cyclic dependencies. If you have a target in multiple export sets, it suggests that you probably should factor out that target to a separate export set that other exports then depend on. That said, if you have a scenario that legitimately requires a target in multiple export sets, then you would need to use multiple install() commands to achieve this, specifying a different export set for each one. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Changed behavior of CPACK_PACKAGE_VERSION generation?
A little late, but finally got a chance to look at this. In CMake 3.12.0,
the CPack version handling in Modules/CPack.cmake was changed to take its
default from the project version, if set. This was implemented but the
following logic:
if(CMAKE_PROJECT_VERSION_PATCH)
...
endif()
This introduced a bug in that a legitimate value of 0 was then treated as
FALSE, so the common case of the value being zero was resulting in the
value being ignored and falling back to the old default, which was 1. This
was fixed in CMake 3.12.1 by changing it to the following:
if(CMAKE_PROJECT_VERSION_PATCH GREATER_EQUAL 0)
...
endif()
As part of that same change, the following block of code was also added:
if(NOT DEFINED CPACK_PACKAGE_VERSION)
set(CPACK_PACKAGE_VERSION "${CPACK_PACKAGE_VERSION_MAJOR}")
if(CPACK_PACKAGE_VERSION_MINOR GREATER_EQUAL 0)
string(APPEND CPACK_PACKAGE_VERSION ".${CPACK_PACKAGE_VERSION_MINOR}")
if(CPACK_PACKAGE_VERSION_PATCH GREATER_EQUAL 0)
string(APPEND CPACK_PACKAGE_VERSION ".${CPACK_PACKAGE_VERSION_PATCH}")
endif()
endif()
endif()
Now, your project has been setting CPACK_PACKAGE_VERSION_PATCH to REPLACEME,
which is not a valid number, so the patch version will no longer be getting
appended to CPACK_PACKAGE_VERSION, as you've observed. This explains at
least the history of what happened. I don't know if it was ever considered
valid to set it to anything other than a number, so it isn't clear whether
this should be considered a regression or not. If you feel strongly enough
that it is, I suggest you create an issue in gitlab
<https://gitlab.kitware.com/cmake/cmake/issues/new> and transfer the
details of this email trail to there.
On Thu, Dec 13, 2018 at 5:32 AM Björn Blissing
wrote:
> Hi,
>
> Today we discovered that our generated CPACK_PACKAGE_VERSION variables
> were broken.
> This is probably related to us updating to a newer version of CMake.
>
> Previously we generated this variable by setting the
> CPACK_PACKAGE_VERSION_MAJOR and CPACK_PACKAGE_VERSION_MINOR to fixed
> values, while CPACK_PACKAGE_VERSION_PATCH was set to variable name.
> This name was then replaced by running a custom target just before
> building. In this target the variable name got replaced with the current
> SVN revision number. This have worked the last years, but now the variable
> name just gets omitted when we run "generate" in CMake.
>
> A short example:
>
> cmake_minimum_required(VERSION 2.8.9)
> project (hello)
> add_executable(hello helloworld.cpp)
> set(CPACK_PACKAGE_VERSION_MAJOR "1")
> set(CPACK_PACKAGE_VERSION_MINOR "0")
> set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME")
> include(CPack)
>
> Would result in the following strings in CPackConfig.cmake:
> ---
> set(CPACK_PACKAGE_VERSION "1.0.REPLACEME")
> set(CPACK_PACKAGE_VERSION_MAJOR "1")
> set(CPACK_PACKAGE_VERSION_MINOR "0")
> set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME")
>
>
> But with the CMake 3.12.2 this will be:
> ---
> set(CPACK_PACKAGE_VERSION "1.0")
> set(CPACK_PACKAGE_VERSION_MAJOR "1")
> set(CPACK_PACKAGE_VERSION_MINOR "0")
> set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME")
>
>
> So our CPACK_PACKAGE_VERSION will omit the variable name, which in turn
> makes our custom target to fail.
>
> Our quick fix was to add the following line to our CMakeList.txt file:
> SET(CPACK_PACKAGE_VERSION
> "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
>
> My question is: Is this change of behavior intended? Are only numbers
> allowed to be part of the CPack version variable?
>
> Regards
> Björn Blissing
>
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Problems with ExternalProject_Add
On Wed, May 22, 2019 at 7:13 PM Steven Truppe wrote:
> Hi everyone,
>
>
> i'm trying to use ExternalProject_Add like the following:
>
> set(BOOST_VERSION 1.68.0)
> set(BOOST_VERSION_NODOTS 1_68_0)
> set(BOOST_URI
> https://dl.bintray.com/boostorg/release/${BOOST_VERSION}/source/boost_${BOOST_VERSION_NODOTS}.tar.gz)
> set(BOOST_HASH 5d8b4503582fffa9eefdb9045359c239)
>
> ExternalProject_Add(external_boost
> PREFIX ${CMAKE_BINARY_DIR}/boost
> URL ${BOOST_URL}
> DOWNLOAD_DIR ${CMAKE_BINARY_DIR}/boost
> URL_HASH MD5=${BOOST_HASH}
> CONFIGURE_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/
> && ./bootstrab --prefix=${OUTPUT_PATH}/boost
> BUILD_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/
> && ./b2
> BUILD_IN_SOURCE 1
> INSTALL_DIR ${OUTPUT_PATH}/boost
>
> The problem is that he tells me that the md5 sum isn't correct, but i did
> md5sum ${BOOST_URL}.
>
>
Looking in the same directory from which you are trying to download, there
is a boost_1_68_0.tar.gz.json file which contains the expected sha256 sum.
You would be better off using that in this case:
set(BOOST_HASH da3411ea45622579d419bfda66f45cd0f8c32a181d84adfa936f5688388995cf)
You'd also need to change the URL_HASH in your call to
ExternalProject_Add():
URL_HASH SHA256=${BOOST_HASH}
Your ExternalProject_Add() command also seems to have a few typos in
various places (BOOST_URL instead of BOOST_URI, the CONFIGURE_COMMAND
contains ./bootstrab which looks suspicious) and you should use separate
COMMAND entries rather than using && to specify multiple commands for a
given stage. Have a read through the ExternalProject_Add() docs for more
details, specifically the "Miscellaneous Options" subsection.
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Is email notification of a failed CMake dashboard possible?
Notifications for builds are controlled through CDash. You can adjust your CDash notifications to suit your preferences. Go to CDash, click on "My CDash". You should see a list of "My Projects" and "Public Projects". Subscribe to a project and it will appear under your "My Projects" area if it isn't there already. For each subscribed project, you should see an icon next to it under the Actions column which allows you to edit your subscription and from there you can control what you receive email notifications for. I'm not sure if there is a way to limit your notifications to just certain sites though. You may need to ask on the CDash mailing list for help with that. On Sun, May 26, 2019 at 7:54 AM Alan W. Irwin wrote: > With a lot of initial configuration help from Brad King, I have been > automatically submitting a Nightly dashboard for CMake (including the > PLplot contract test) for some time now (see the "merlin" results at > <https://open.cdash.org/index.php?project=CMake> and > <https://open.cdash.org/index.php?project=KWSys>). On extremely rare > occasions there is a failure in either of my CMake or KWSYS > dashboards. Is it possible for me to set up e-mail notification of > such failures (and successes at first to make sure notification > works), and if so, how? > > 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 > __ > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake-developers > -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Problem with foreach() iteration over a list that uses generator expressions
On Tue, May 7, 2019 at 12:27 AM Tadeusz A. Kadłubowski <
tadeusz.kadlubow...@pix4d.com> wrote:
> Hi,
>
> I have an `INTERFACE IMPORTED` library target that depends on a bunch
> of optional dependencies. Please see the snippet below:
>
> cmake_minimum_required(VERSION 3.14)
>
> add_library(example INTERFACE IMPORTED)
> set_property(TARGET example PROPERTY INTERFACE_LINK_LIBRARIES
> $<$:${undefined_dependency_one}
> ${undefined_dependency_two}>
> )
>
If your generator expression contains spaces, you need to surround the
whole expression with quotes:
set_property(TARGET example PROPERTY INTERFACE_LINK_LIBRARIES
"$<$:${undefined_dependency_one} ${undefined_dependency_two}>"
)
Note that in this case, the space is unlikely to actually be what you want
because the above would end up adding a single library named
"${undefined_dependency_one} ${undefined_dependency_two}"
> It so happens that both of the optional dependencies
> `${undefined_dependency_one}` and `${undefined_dependency_two}` are
> set to empty/undefined on my system, which is perfectly fine.
>
> I want to do some postprocessing to the dependencies of my target:
>
> get_target_property(all_dependencies example INTERFACE_LINK_LIBRARIES)
> foreach(lib IN LISTS all_dependencies)
> message(STATUS "dependency on " ${lib})
> endforeach()
>
> This `foreach()` loop gets confused about the generator expression.
> The output of the `message(STATUS ...)` calls in the snippet above is:
>
> -- dependency on $<$:
> -- dependency on >
>
> Please note that the generator expression got mangled into two pieces
> by the `foreach()` loop. I was expecting to see a single line of
> `$<$:>`
>
> I experimented with different versions of this test case and found
> variants that do not get mangled in the `foreach()` loop. In a
> modification when there is only one empty/undefined dependency the
> `foreach()` loop works as expected.
>
> set_property(TARGET example PROPERTY INTERFACE_LINK_LIBRARIES
> $<$:${undefined_dependency_one}>
> )
>
> A modification in which each empty/undefined dependency is surrounded
> with its own generator expression works correctly too:
>
> set_property(TARGET example PROPERTY INTERFACE_LINK_LIBRARIES
> $<$:${undefined_dependency_one}>
> $<$:${undefined_dependency_two}>
> )
>
This would be the way to achieve what you seem to be wanting to do.
>
> Is that a bug in how CMake handles generator expressions? Am I
> misunderstanding some CMake language concepts here?
>
> (all code tested with CMake 3.14.3 on Ubuntu 18.04)
>
> I would be grateful on any feedback about what's going on in that
> `foreach` loop.
>
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] ctest // fixtures and --repeat-until-fail
On Tue, Apr 16, 2019 at 11:36 PM Sergei Nikulov wrote: > > > > On Tue, Apr 16, 2019 at 10:07 PM Sergei Nikulov < > sergey.niku...@gmail.com> wrote: > >> > >> Hello All, > >> > >> Has anybody knows how FIXTURES_SETUP/FIXTURES_CLEANUP should work with > >> --repeat-until-fail option? > >> > >> My expectation, if I requesting a test run for example 10 times, the > >> sequence should be as follows: > >> > >> fixture_setup, then test, then fixture_cleanup repeats 10 times > >> > >> But in practice, I've got following sequence > >> > >> 1. fixture_setup runs 10 times > >> 2. test runs 10 times > >> 3. fixture_cleanup runs 10 times > >> > >> Is it expected behavior? > >> I'm using ctest version 3.14.2 > > > > > > The documentation for the --repeat-until-fail option says "Require each > test to run times without failing in order to pass". A fixture setup or > cleanup test is still a test, so they will also be run times. The logic > that implements repeating tests sets up a counter on each test and it runs > that test times before marking that test as complete. This is why you > see fixture_setup run 10 times, then test runs 10 times and lastly > fixture_cleanup runs 10 times. > > > > I understand that fixture is still a test. > To achieve repeatable behavior -R "test_continues_*" is enough. > > But if it calls FIXTURE why not apply the specific behavior as > expected from fixture (init/teardown)? > It's mostly related to the way it is implemented internally. Because a fixture setup/cleanup is still just another test, it has all the features of a regular test, including honouring the option that tells ctest to run it multiple times. For some projects, it may be desirable for the fixture setup/cleanup to run only once but re-run the fixture-requiring test(s) to run multiple times. For other projects, it might be desirable for the fixture setup/cleanup tests to also run multiple times (a setup test might simply be polling a service to confirm it is up, for example). Since ctest cannot know which of the two scenarios the project wants, it simply treats all tests the same, whether they are fixture setup/cleanup tests or not. Perhaps one way of dealing with this might be to add a new boolean test property which, when set, has the meaning of "only run once" when the --repeat-until-fail option is used. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Possible inconsistent behavior in target_sources() and CMake 3.14
On Wed, Apr 3, 2019 at 11:10 AM Michele Rosso wrote: > Hello, > according to the doc for CMake 3.14, target_sources() interprets relative > source file paths as being relative to the current source directory, i.e. > it should > prepend CMAKE_CURRENT_SOURCE_DIR to the relative paths given by the user. > However, this is not the case if the target and the sources are defined in > the same directory. > The docs say that target_sources() will *interpret* relative source file paths that way, but they do not state that it will prepend CMAKE_CURRENT_SOURCE_DIR. The docs for target_sources() only talk about how relative paths are interpreted. The docs for policy CMP0076 are a bit more explicit, but even they only say that target_sources() will convert the relative path to absolute *if the conditions also specified in those policy docs are met*. In the case where target_sources() is called in the same directory as where the target is defined, the target's SOURCE_DIR property and the CMAKE_CURRENT_SOURCE_DIR variable will hold the same value, so the relative path is not modified, as per the CMP0076 docs. > I attached a simple example to reproduce the issue. The structure of the > example is as follows: > > - cmake-bug/ > - CMakeLists.txt > - main.cpp > - foo/ > - CMakeLists.txt > - foo.H > - foo.cpp > - bar/ > - CMakeLists.txt > - bar.H > - bar.cpp > > Target "main.exe" is defined in the top-level CMakeLists.txt, while its > headers and sources are located in the the top-level directory > and in the sub-directories 'foo' and 'bar'. > After target_sources is used to include all the headers and sources, I > retrieve the "SOURCES" property for `main.exe`: all the sources and headers > but `main.cpp` are given the correct (absolute) path. > > Is this the intended behavior? If so, why should a source file located in > the same directory where the target is defined be treated any differently? > Yes, this is the intended behavior. There's no need to modify the path when target_sources() is called in the same directory as that in which the target is defined because the behavior is unambiguous and is the same whether CMP0076 is set to OLD or NEW. This is consistent with what you'd get if you had listed the sources directly in the add_executable() or add_library() call instead. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] linking FetchContent library
(Please continue to CC the mailing list with replies)
On Thu, Apr 11, 2019 at 4:22 PM Stéphane Ancelot
wrote:
>
> Le 10/04/2019 à 23:03, Craig Scott a écrit :
>
>
>
> On Thu, Apr 11, 2019 at 1:35 AM Stéphane Ancelot
> wrote:
>
>> Hi,
>>
>> are there any specific Cmake configurations to setup in projects when
>> using fetchcontent.
>>
>> I am able to fetch and build a library but not able to link and include
>> files of this library in another projects.
>>
>> include(FetchContent)
>>
>> FetchContent_Declare(
>> jconcpp
>> GIT_REPOSITORY https://github.com/joncol/jcon-cpp.git
>> )
>>
>> FetchContent_Populate(jconcpp)
>> add_subdirectory(${jconcpp_SOURCE_DIR} ${jconcpp_BINARY_DIR})
>>
> add_subdirectory(projA)
>
> Can you provide a complete minimal example which shows the problem? The
> snippet above should bring jsoncpp into your main build, but without seeing
> how you are trying to link to it's targets, it is hard to tell what the
> problem could be.
>
>
> fetchcontent is done in the main CMakeLists.txt
>
> I have a projA dir
>
> projA/CMakeLists.txt
>
> cmake_minimum_required(VERSION 3.10)
> project(proja)
>
> add_executable(proja
>proja.cpp)
>
> target_link_libraries(proja jconcpp)
>
There is no target in the jcon-cpp project by the name "jconcpp". The only
library I can see in that project is one called "jcon". Note that you need
to link against CMake targets, not against the dependency name used in the
call to FetchContent_Declare().
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] linking FetchContent library
On Thu, Apr 11, 2019 at 1:35 AM Stéphane Ancelot
wrote:
> Hi,
>
> are there any specific Cmake configurations to setup in projects when
> using fetchcontent.
>
> I am able to fetch and build a library but not able to link and include
> files of this library in another projects.
>
> include(FetchContent)
>
> FetchContent_Declare(
> jconcpp
> GIT_REPOSITORY https://github.com/joncol/jcon-cpp.git
> )
>
> FetchContent_Populate(jconcpp)
> add_subdirectory(${jconcpp_SOURCE_DIR} ${jconcpp_BINARY_DIR})
>
Can you provide a complete minimal example which shows the problem? The
snippet above should bring jsoncpp into your main build, but without seeing
how you are trying to link to it's targets, it is hard to tell what the
problem could be.
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Parent component options passed to ExternalProject
On Tue, Mar 26, 2019 at 4:02 AM Dustyn Blasig wrote: > Hi All, > > I'm really struggling to use ExternalProject_Add() in our CMake project. > > Based on the documentation, I was expecting the simplest Git-based > external project with all defaults to act just like using a Git submodule > locked at a specific commit. > > include(ExternalProject)ExternalProject_Add(foobar GIT_REPOSITORY > g...@github.com:FooCo/FooBar.git GIT_TAG origin/release/1.2.3) > > The documentation states "The default configure command runs CMake with > options based on the main project.", so I was expecting any options we pass > to the owning project such as CMAKE_INSTALL_PREFIX and other variables > would get propagated to the ExternalProject. However, that doesn't seem to > be the case. Do I need to explicitly apply every variable through the > "CMAKE_ARGS" options? If so, > Some basic details are passed down to the external project, but I don't recall exactly which variables. I don't think there are a lot of them and I do tend to find that I need to pass down some vars in my own projects. You may have to dig into the ExternalProject module's source to get confirmation for yourself, possibly also look into what the external_process() command's implementation does as well. > Also, unless I specify a custom CONFIGURE_COMMAND, I can't figure out how > to make the configure step happen during the parent projects configure > step. Should that be happening? If not, is there a simple way to force it > to happen without having to duplicate everything the default options do? > I'm seeing mixed results with online resources, along with many older > examples that just don't work anymore. > The external project's configure step happens during the main project's build stage, just like every other step of ExternalProject_Add(). This will be the case whether you override the CONFIGURE_COMMAND or not. If you really need the configure step to occur during the main project's configure stage, then you have at least a couple of options: - Consider using the FetchContent module instead and bring the external project into your main build directly. If this suits your scenario, then I'd recommend this method. I use this a lot and it seems to be growing in popularity. It requires CMake 3.11 or later. - Go for a pure superbuild approach where your main project does nothing more than call various ExternalProject functions to tie together different external projects (i.e. your main project doesn't add any targets, etc. of its own). This will mean that even though the configure steps all occur during the main project's build step, you can control the dependencies between the different external projects' steps so that they can find what they need from each other (I'm guessing here that you want the external project's configure stage to run during your main project's build stage so that something later in your main project's configure stage can make use of something the external project's configure stage does). You will still have to explicitly specify a number of variables to be passed through to each external project's configure stage though, so maybe this doesn't solve the problem you are facing. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] FetchContent or Export Targets
On Sun, Mar 24, 2019 at 1:43 PM Jason Beach wrote: > Hi, > As I've been learning CMake, it seems the best practice for a library is > for it to export the targets it creates. There is also the relatively new > command FetchContent. It seems that at least in part the FetchContent > command obviates the need for exporting targets. > > I can see that for larger more permanent libraries exporting targets is > still preferred so the library can be installed once and used by multiple > projects on a developers workstation without having to install it on each > project. > > At work we're a bunch of research engineers that happen to write a lot of > software-- exporting targets still seems cumbersome and it seems not > exporting targets and then just have users use FetchContent to pull in a > library is not a bad idea. > > Are there other reasons /advantages of exporting targets? > Exporting targets is a way to allow other projects to easily consume yours via find_package(). If you are 100% confident that no-one is ever going to use your project that way and will only ever build it from source directly (whether that be through FetchContent or some other method), then there's no benefit to exporting targets. As soon as there's a possibility that someone might want to build against an installed version of your project though, having the exported targets available makes for a significantly more convenient and more robust experience. It really comes down to whether in your case you can truly say no-one will ever want to use find_package() to bring your projects into theirs. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] conflict between configure & build steps in gitlab-runner script for Windows: Debug or Release build directory not found
You have put -j8 before the --build option, but the --build option must be the first one. This ordering requirement is stated in the docs <https://cmake.org/cmake/help/latest/manual/cmake.1.html#build-a-project> for the --build option in the "Build A Project" section. On Sat, Mar 23, 2019 at 1:00 AM Joachim Wuttke wrote: > A gitlab-runner configuration script .gitlab-ci.yml, for execution in the > Powershell: > > === > windows: >tags: >- windows >stage: build >script: > - New-Item -ItemType "directory" -Confirm:$false -Force:$true -Name > "build" > - cd build > - cmd.exe "C:\Program Files (x86)\Microsoft Visual > Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat" > - cmake -G "Visual Studio 15 2017" -A x64 -T host=x64 -DCERF_CPP=ON > -DLIB_MAN=OFF -DLIB_INSTALL=OFF -B. .. > - cmake -j8 --build . --config Debug > - ctest -j4 > === > > results in > > === > $ cd build > $ cmd.exe "C:\Program Files (x86)\Microsoft Visual > Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat" > Microsoft Windows [Version 10.0.17134.648] > (c) 2018 Microsoft Corporation. All rights reserved. > > C:\gitlab-runner\builds\s-nngMTK\0\mlz\libcerf\build>$ cmake -G "Visual > Studio 15 2017" -A x64 -T host=x64 -DCERF_CPP=ON -DLIB_MAN=OFF > -DLIB_INSTALL=OFF -B. .. > -- The CXX compiler identification is MSVC 19.16.27026.1 > -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe > -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.16.27023/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 > Build C++ library libcerfcpp > -- libcerf/lib: build library cerfcpp, CERF_CPP=ON, shared=ON > -- Configuring done > -- Generating done > -- Build files have been written to: > C:/gitlab-runner/builds//libcerf/build > $ cmake -j8 --build . --config Debug > CMake Error: The source directory > "C:/gitlab-runner/builds//libcerf/build/Debug" does not exist. > Specify --help for usage, or press the help button on the CMake GUI. > > ERROR: Job failed: exit status 1 > === > > How to resolve this conflict between the configure step (cmake) and > the build step (cmake --build)? > > The latter won't work without the option "--config Debug"; > but if that option is given, then it looks for a nonexistent directory. > > The same problem occurs with "--config Release". > > /Joachim > > > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Passing CMake Arguments to FetchContent
On Sat, Mar 23, 2019 at 1:58 PM Jason Beach wrote: > I'm upgrading from cmake 3.5.1 and am trying to understand the new > FetchContent command. So far I have: > > cmake_minimum_required(VERSION 3.14) > project (json_test) > > include(FetchContent) > set(JSON_BuildTests OFF) #if I try this I get a warning as it appears to > be deprecated > > FetchContent_Declare( > nlohmann_json_fc > GIT_REPOSITORY https://github.com/nlohmann/json.git > GIT_TAG v3.6.1 > GIT_SHALLOW TRUE > #CMAKE_ARGS -DJSON_BuildTests=OFF #doesn't work > ) > FetchContent_MakeAvailable(nlohmann_json_fc) > add_executable(main src/main.cpp) > target_link_libraries(main nlohmann_json::nlohmann_json) > > > I first tried sending in the JSON_BuildTests=OFF with CMAKE_ARGS in the > FetchContent_Declare command but that didn't work. On this post > https://cmake.org/pipermail/cmake/2018-July/067804.html it appears this > is because only the download portion of FetchContent_Declare is enabled > with the intent to not do too much during configure time. How does > specifying how the external project is configured fit that rationale? If I > execute > > cmake -DJSON_BuildTests=OFF .. > > the argument successfully makes it through to the external project. I > guess I'm trying to understand why it's ok to specify it on the command > line but not permanently in the CMakeLists.txt, particularly if you have > many libraries each potentially with their options that need to be > configured. > The warning you are getting is due to the behavior of the option() command, which was changed in CMake 3.13. The first time you run CMake, the JSON_BuildTests variable is not in the cache. With CMake 3.12 and earlier, the option command will then ignore any non-cache variable of the same name and set the cache variable to the default value. This has the side-effect of also removing/updating the local variable, which means any non-cache variable you set before the call to option() will have no effect the first time you run CMake, but then it WILL have an effect for subsequent runs. This is unintuitive and easy to miss. In CMake 3.13, the behavior was changed to not create a cache variable if there was already a non-cache variable set. This is intuitively what developers typically expect, but it is only done if the CMP0077 policy is set to new. Inside the nlohmann/json project's CMakeLists.txt file, it uses cmake_minimum_required(VERSION 3.1), which means the CMP0077 policy is not set to NEW, hence the warning you are seeing. To prevent this problem in your case, you will need to set JSON_BuildTests as a cache variable in your example project rather than just a regular non-cache variable. Then the option() command in the nlohmann/json project sees that the cache variable has already been set and it does nothing instead of forcing it to have the default value on the first run. I typically handle this situation in my projects by setting such variables to an INTERNAL type where the main project is forcing the value and it won't be available to the developer to change (so you don't want to show it to them in the GUI, etc.). If you still want the developer to be able to override it, just put an option command with your own preferred default here instead. For your case, the modified example would be the following: cmake_minimum_required(VERSION 3.14) project (json_test) include(FetchContent) set(JSON_BuildTests OFF CACHE INTERNAL "") # Forces the value #option(JSON_BuildTests "" OFF) # Different default, but dev can still change it FetchContent_Declare( nlohmann_json_fc GIT_REPOSITORY https://github.com/nlohmann/json.git GIT_TAG v3.6.1 GIT_SHALLOW TRUE ) FetchContent_MakeAvailable(nlohmann_json_fc) add_executable(main src/main.cpp) target_link_libraries(main nlohmann_json::nlohmann_json) -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[cmake-developers] CMAKE_XCODE_GENERATE_SCHEME still documented as experimental
The CMAKE_XCODE_GENERATE_SCHEME variable has been available in CMake since about the 3.9 release. Its documentation states that the Xcode Schema Generator is still experimental and subject to change, but is this still the case? Would it be appropriate to remove that note from the docs now? -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] include_extenal_msproject() dependency behavior change between 3.13.4 and 3.14.0-rc2 (possible bug in rc2)
On Tue, Feb 26, 2019 at 10:06 PM wrote:
> Hi Craig,
>
> Thanks for the info. I've verified that the revision you pointed me to
> (24b6e4830d9027e63db7dfafa500aaeb652d3a4c) is where the behavior broke
> (I built CMake using the revision directly before this one and
> everything still works fine). I'm no expert with CMake development -
> could someone chime in on whether what I am seeing is expected or
> whether something has inadvertently been broken?
>
> Testing this is actually quite simple. There is no need to even have
> valid external vcproj files on the file system - CMake does not appear
> to care if they exist or not when generating the solution. The most
> trivial test I can give to reproduce the behavior is:
>
> ./CMakeLists.txt:
> cmake_minimum_required(VERSION 3.4)
> project(frontend_test)
> add_subdirectory(deps "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
> EXCLUDE_FROM_ALL)
> add_executable(frontend1 main.c)
> target_link_libraries(frontend1 foo1_cmake)
>
> ./main.c:
> /* nothing - unimportant for the test */
>
> ./deps/CMakeLists.txt:
> cmake_minimum_required(VERSION 3.4)
> add_library(foo1_cmake STATIC IMPORTED GLOBAL)
> include_external_msproject(foo1_cmake_extern "foo1.vcproj")
> add_dependencies(foo1_cmake foo1_cmake_extern)
> set_property(TARGET foo1_cmake PROPERTY IMPORTED_LOCATION_DEBUG
> "foo1.lib")
> add_library(foo2_cmake STATIC IMPORTED GLOBAL)
> include_external_msproject(foo2_cmake_extern "foo2.vcproj")
> add_dependencies(foo2_cmake foo2_cmake_extern)
> set_property(TARGET foo2_cmake PROPERTY IMPORTED_LOCATION_DEBUG
> "foo2.lib")
>
> Invoking CMake before revision 24b6e4830d9027e63db7dfafa500aaeb652d3a4c
> and opening the solution will show that Visual Studio would like to open
> foo1_cmake_extern (and it will show as unavailable in the solution
> explorer on account of the file not actually existing).
>
> Invoking CMake at or after revision
> 24b6e4830d9027e63db7dfafa500aaeb652d3a4c and opening the solution will
> show that Visual Studio would like to open foo1_cmake_extern AND
> foo2_cmake_extern (and both will show as unavailable in the solution
> explorer on account of the file not actually existing).
>
Thanks, I've recorded this in the bug tracker as issue 18986
<https://gitlab.kitware.com/cmake/cmake/issues/18986>
> Just as an FYI for the mailing list (I don't actually care about this):
> I needed to update on my machine CMake (I was previously running version
> 3.6) to build CMake. This might be acceptable - but I figured that CMake
> should have used cmake_version_minimum to indicate the version I was
> using was not new enough. I did not investigate, but 3.6 bombed out with
> the following:
>
> C:\cmakegit\cmake\build> cmake .. -G "Visual Studio 14 2015 Win64"
> CMake Error at Tests/RunCMake/CMakeLists.txt:279 (if):
>if given arguments:
>
> "(" "CMAKE_CXX_COMPILER_VERSION" "VERSION_GREATER_EQUAL"
> "19.0.24215.1" "AND" "CMAKE_CXX_COMPILER_VERSION" "VERSION_LESS" "19.10"
> ")" "OR" "CMAKE_CXX_COMPILER_VERSION" "VERSION_GREATER_EQUAL"
> "19.10.25017"
>
>Unknown arguments specified
>
This looks unintentional too. Recorded as issue 18987
<https://gitlab.kitware.com/cmake/cmake/issues/18987>.
>
> Nick Appleton
>
> On 2019-02-26 19:44, Craig Scott wrote:
> > If you're able to build CMake from sources yourself, you may want to
> > check if the changes from this merge request [2] are what has led to
> > the change you're seeing. That relates to how the EXCLUDE_FROM_ALL
> > target property is initialised when a target is created.
> >
> > On Tue, Feb 26, 2019 at 2:20 PM wrote:
> >
> >> Hello,
> >>
> >> We have a fairly large CMake project which uses
> >> include_extenal_msproject() when we are producing Visual Studio
> >> solutions to bring in projects produced using another build metadata
> >>
> >> generator. We've noticed most of our Visual Studio builds have
> >> started
> >> failing after switching to CMake 3.14.0-rc2 (not sure where betweenn
> >>
> >> 3.13.4 and 3.14.0-rc2 this issue was introduced).
> >>
> >> An example of how the behavior differs can be realised with the
> >> following example:
> >>
> >> dependencies/CMakeLists.txt:
> >>
> >> # several duplications of the following block exist replacing fooN
> >> with
> >> foo1, foo2, foo3, etc.
> >> add_library(fooN_cmake STATIC IMPORTED G
Re: [CMake] include_extenal_msproject() dependency behavior change between 3.13.4 and 3.14.0-rc2 (possible bug in rc2)
If you're able to build CMake from sources yourself, you may want to check
if the changes from this merge request
<https://gitlab.kitware.com/cmake/cmake/merge_requests/2816> are what has
led to the change you're seeing. That relates to how the EXCLUDE_FROM_ALL
target property is initialised when a target is created.
On Tue, Feb 26, 2019 at 2:20 PM wrote:
> Hello,
>
> We have a fairly large CMake project which uses
> include_extenal_msproject() when we are producing Visual Studio
> solutions to bring in projects produced using another build metadata
> generator. We've noticed most of our Visual Studio builds have started
> failing after switching to CMake 3.14.0-rc2 (not sure where betweenn
> 3.13.4 and 3.14.0-rc2 this issue was introduced).
>
> An example of how the behavior differs can be realised with the
> following example:
>
> dependencies/CMakeLists.txt:
>
> # several duplications of the following block exist replacing fooN with
> foo1, foo2, foo3, etc.
> add_library(fooN_cmake STATIC IMPORTED GLOBAL)
> if(MSVC)
>include_external_msproject(fooN_cmake_extern "fooN.vcproj")
> else()
># other external things happen here using ExternalProject_add to end
> up creating fooN_cmake_extern for non-VS/non-Windows builds.
> endif()
> add_dependencies(fooN_cmake fooN_cmake_extern)
> set_property(TARGET fooN_cmake PROPERTY INTERFACE_INCLUDE_DIRECTORIES
> "path to foo include files")
> set_property(TARGET fooN_cmake PROPERTY IMPORTED_LOCATION_DEBUG "path to
> foo static library")
> # ... more properties possibly set
>
> frontend1/CMakeLists.txt:
>
> add_subdirectory(../dependencies "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
> EXCLUDE_FROM_ALL)
> add_executable(frontend1 main.c)
> target_link_libraries(frontend1 foo1_cmake foo2_cmake)
>
> frontend2/CMakeLists.txt:
>
> add_subdirectory(../dependencies "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
> EXCLUDE_FROM_ALL)
> add_executable(frontend2 main.c)
> target_link_libraries(frontend2 foo3_cmake foo2_cmake)
>
> The old behavior: we could invoke CMake using a source directory of
> frontend1 or frontend2 to get Visual Studio solutions. Only the Visual
> Studio projects which are imported using include_extenal_msproject()
> that are dependencies of that particular frontend are included in the
> solution i.e. the VS solution for frontend1 will not include foo3_cmake
> as part of the build at all. I expect this due to the use of
> EXCLUDE_FROM_ALL.
>
> The new behavior: all frontends will include every single project
> defined using include_extenal_msproject that CMake encounters. They will
> all attempt to be built regardless of if there is a dependency. I would
> only have expected this behavior if EXCLUDE_FROM_ALL was *not* set when
> using add_subdirectory().
>
> Could someone help me to understand if the behavior change is expected
> or if this is just a bug?
>
> Thanks!
>
> Nick Appleton
> --
>
> 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
>
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Ensuring an external project is built and installed before trying to call "find_package" on it
On Sat, Feb 23, 2019 at 4:14 PM Timothy Wrona wrote:
> I am working on a CMake project that depends on a couple other projects I
> have previously written. I would like to include those other projects using
> "ExternalProject_Add", but I am having some issues.
>
> The basic layout of the project is this:
>
> cmake_minimum_required(VERSION 3.14.0)
>
> project(ProjectWithDependencies)
>
> include(ExternalProject)
> ExternalProject_Add(Dependency1
> GIT_REPOSITORY
> )
> ExternalProject_Add(Dependency2
> GIT_REPOSITORY
> )
>
> find_package(Dependency1 Required)
> find_package(Dependency2 Required)
>
> # Use targets
>
> I was under the assumption that "ExternalProject_Add" would automatically
> build and install the dependencies before getting to the "find_package"
> calls (they are CMake projects so the default build and install commands
> should be fine) but this doesn't seem to be how it works.
>
> When I get to "find_package" it fails because the dependency hasn't been
> installed yet.
>
> How can I ensure that the dependencies are fully compiled and installed
> before attempting to find them? (Note: FetchContent doesn't work here
> because the two projects "Dependency1" and "Dependency2" have targets with
> the same name which causes FetchContent to fail.)
>
> Any help is appreciated.
>
find_package() requires that the dependencies have been built already, as
you've noted. When CMake runs and processes your example CMakeLists.txt
file, it sets up the build rules for Dependency1 and Dependency2, but they
won't actually be configured, built and installed until you build the main
project. Since your find_package() calls will be processed during the
configure stage of the main project (i.e. before the build stage), it's too
early.
To address this, you need to make your main project a true superbuild where
it basically contains nothing more than a set of ExternalProject_Add()
calls. Rather than putting the find_package() calls and use of targets
directly in the main build, you can add it as another sub-build. Note that
this will mean that none of the targets you define in the mainBuild will be
visible as targets in your top level superbuild project. I'd also advise
you to override the default install location of your dependencies.
Otherwise they will typically try to install to a system-wide location,
which is not usually a good thing. Putting it together, the top level
superbuild project would look something like this:
cmake_minimum_required(VERSION 3.14.0)
project(ProjectWithDependencies)
set(installDir ${CMAKE_CURRENT_BINARY_DIR}/install)
include(ExternalProject)
ExternalProject_Add(Dependency1
GIT_REPOSITORY
INSTALL_DIR${installDir}
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=
)
ExternalProject_Add(Dependency2
GIT_REPOSITORY
INSTALL_DIR${installDir}
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=
)
ExternalProject_Add(mainBuild
SOURCE_DIR
INSTALL_DIR ${installDir}
DEPENDS Dependency1 Dependency2
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=
-DCMAKE_PREFIX_PATH:PATH=
)
Or you could make the superbuild a completely separate repo and then use
GIT_REPOSITORY rather than SOURCE_DIR for the "mainBuild" part.
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Using FetchContent fails when two subprojects have a target with the same name
On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona wrote: > (Included cmake-developers list as well in case this may have just been > something that should work that was overlooked with the FetchContent module) > > On Tue, Feb 19, 2019 at 11:32 PM Timothy Wrona > wrote: > >> I am having an issue with using FetchContent to grab two subprojects that >> both contain a "doxygen" target to build the documentation. >> >> Both of these subprojects need to be able to be built independently and >> when built on their own they compile fine (along with their documentation), >> but when I pull them into one project using "FetchContent" I get an error >> saying I can't define the "doxygen" target more than once. >> >> I imagine this kind of issue would come up all of the time when using a >> "superbuild" pattern. Is there a typical way of handling this? >> > I thought this limitation was already mentioned in the FetchContent docs, but it seems it isn't. If two different dependencies define the same global target name, then they cannot be combined into the same build via add_subdirectory(). CMake doesn't allow a target to be redefined (although it does allow additional commands to be added to an existing custom target). I'll try to add some docs to FetchContent to mention this limitation, but they will not make it into the 3.14 release - the limitation has always been there right from when FetchContent was first introduced in 3.11. A traditional superbuild that uses ExternalProject won't have a problem with this because a subproject's own targets are not combined with targets of other subprojects into a single build. Instead, the top level project only sees the targets that ExternalProject itself creates. This is most likely the best workaround if you are not able to modify the target names used in the subprojects you want to combine. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Using FetchContent fails when two subprojects have a target with the same name
On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona wrote: > (Included cmake-developers list as well in case this may have just been > something that should work that was overlooked with the FetchContent module) > > On Tue, Feb 19, 2019 at 11:32 PM Timothy Wrona > wrote: > >> I am having an issue with using FetchContent to grab two subprojects that >> both contain a "doxygen" target to build the documentation. >> >> Both of these subprojects need to be able to be built independently and >> when built on their own they compile fine (along with their documentation), >> but when I pull them into one project using "FetchContent" I get an error >> saying I can't define the "doxygen" target more than once. >> >> I imagine this kind of issue would come up all of the time when using a >> "superbuild" pattern. Is there a typical way of handling this? >> > I thought this limitation was already mentioned in the FetchContent docs, but it seems it isn't. If two different dependencies define the same global target name, then they cannot be combined into the same build via add_subdirectory(). CMake doesn't allow a target to be redefined (although it does allow additional commands to be added to an existing custom target). I'll try to add some docs to FetchContent to mention this limitation, but they will not make it into the 3.14 release - the limitation has always been there right from when FetchContent was first introduced in 3.11. A traditional superbuild that uses ExternalProject won't have a problem with this because a subproject's own targets are not combined with targets of other subprojects into a single build. Instead, the top level project only sees the targets that ExternalProject itself creates. This is most likely the best workaround if you are not able to modify the target names used in the subprojects you want to combine. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] [cmake-developers] Using CMake as a package manager vs using a dedicated package management tool (like Conan)
ter fit for this scenario. > - Maybe when the sub-project libraries reach a mature and stable > release they should be packaged into Conan and fetched in the main > project > from Conan at that point? > > Let me know what you think! :) > Sounds like you are making progress exploring things already, you'll need to make your own evaluations about which approach will work best for you. As a data point, in my day job, most of the time I'm working with a project hierarchy that spans about 40+ dependencies, most of which are internal projects that can all be built standalone or as part of a larger whole. Some are small and relatively trivial, others are much larger and have varying age with the associated quirks that come with that. Most come from git but some come from svn and a small number from release tarballs. Some have code generators that also produce CMakeLists.txt files that other parts of the build need to consume (see this stack overflow Q <https://stackoverflow.com/q/36084785/1938798> for more on that). We use both GoogleTest and Boost, plus various other third party projects (OpenSSL is probably the one that gives us the most pain). We build for Linux, Windows, Mac, Solaris, iOS and Android. We support our devs building with Make, Ninja, Xcode or Visual Studio (we don't use MinGW). Many of the projects are actively undergoing change across multiple teams and people, most of whom don't have an interest in learning about CMake and build systems and just want to focus on coding. The flexibility and robustness that FetchContent has given us has been a critical factor in being able to work effectively and efficiently. That and ccache. ;) We don't use a package manager other than letting the OS provide some common things on a few platforms. For some larger dependencies (e.g. NDK, Qt) we rely on having pre-built packages installed at predictable locations and accept that we will have to maintain these on our build slaves, although this is an area that is still evolving. I recently posted <https://gitlab.kitware.com/cmake/cmake/issues/18831#note_509194> how I'm currently working on bringing Boost into our build via a FetchContent-based mechanism. That is still somewhat of a work-in-progress and has holes for multi-config generators (i.e. Visual Studio and Xcode), but they don't look insurmountable if those are important to you. It's by no means the only approach, but it's a starting point if you want to explore it (once Boost completes its move to CMake, I hope to be able to drop this and just bring Boost into the build via add_subdirectory() like most of our other dependencies). > > > On Tue, Feb 19, 2019 at 5:56 AM Craig Scott > wrote: > >> >> >> On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona >> wrote: >> >>> I have been working on a new C++ project and I am trying to decide >>> whether I should use CMake as my package management system or if I should >>> use a dedicated package management tool such as Conan. >>> >>> For more information on Conan see: https://conan.io/ >>> >>> I am trying to understand the main difference between using Conan to >>> manage dependencies vs using CMakes "FetchContent" module. Are there any >>> compelling reasons to prefer something like Conan? >>> >> >> Excellent question, one that I think deserves a more detailed answer than >> I can provide here, but I'll try to hit the main points as I see them. >> >> Personally, I think there is no "right answer" or "one size fits all" >> when it comes to package management for a CMake project. What works well >> for one situation, person or project may not be as convenient or suitable >> for another. There are competing needs and views, some of which are >> personal preferences, others are hard requirements from things like OS >> distribution policies for packaging. Even just the maturity of a project >> can have a big influence on how developers may prefer to handle its >> dependencies and handle it as a dependency of other projects. >> >> The key thing for me is that the developer should ideally have choices >> when it comes to this area. If a project hard-codes that its dependencies >> must come from a particular provider (whether that be Conan, Hunter, vcpkg >> or some other system), this might not be compatible with what the >> developer's situation allows. You would need to weigh up whether it makes >> sense to lock the developer into a particular package manager if they want >> to use your project or not. An inappropriate choice here can mean lower >> adoption of the project as some may reject it for consideration based on >> this point alone. >> >> If instead a proj
Re: [CMake] [cmake-developers] Using CMake as a package manager vs using a dedicated package management tool (like Conan)
work in them)? What will be the impact on developers working on the project when these dependencies need to be updated (how easy is it for them to update, what assumptions are you making about their development environment and tools)? - What breadth of platforms, compilers and CMake generators do you want to support? The bigger this set, the more it may drive you towards building dependencies from source rather than relying on having pre-built packages available to you. - Do you want developers to be able to use tools like sanitizers, perform code refactoring across projects or have source code visibility into dependencies within their IDE tools? FetchContent supports all of these requirements quite naturally, but doing so for the other methods it may be more difficult. - How will you manage repeatability of building past releases? Will you be able to build a year old release again if you update a build slave? In particular, what assumptions are you making about a CI system's build slaves and what dependencies they have installed (can you have multiple versions of any given dependency available at once, whether that be at a known path or via whatever package manager(s) you choose to use)? On a side note, this is an area I'm increasingly thinking about these days (I'm the author of the FetchContent module). I'm interested in hearing peoples' views on dependency management and building an understanding of what works for people and what doesn't. If you want to send feedback my way, do feel free to get in touch. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Using CMake as a package manager vs using a dedicated package management tool (like Conan)
work in them)? What will be the impact on developers working on the project when these dependencies need to be updated (how easy is it for them to update, what assumptions are you making about their development environment and tools)? - What breadth of platforms, compilers and CMake generators do you want to support? The bigger this set, the more it may drive you towards building dependencies from source rather than relying on having pre-built packages available to you. - Do you want developers to be able to use tools like sanitizers, perform code refactoring across projects or have source code visibility into dependencies within their IDE tools? FetchContent supports all of these requirements quite naturally, but doing so for the other methods it may be more difficult. - How will you manage repeatability of building past releases? Will you be able to build a year old release again if you update a build slave? In particular, what assumptions are you making about a CI system's build slaves and what dependencies they have installed (can you have multiple versions of any given dependency available at once, whether that be at a known path or via whatever package manager(s) you choose to use)? On a side note, this is an area I'm increasingly thinking about these days (I'm the author of the FetchContent module). I'm interested in hearing peoples' views on dependency management and building an understanding of what works for people and what doesn't. If you want to send feedback my way, do feel free to get in touch. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] Question about set
On Tue, Feb 19, 2019 at 4:16 AM Kyle Edwards via CMake wrote: > On Mon, 2019-02-18 at 17:59 +0100, Andreas Naumann wrote: > > Hey, > > > > I would introduce a list with the allowed values and introduce a > > macro > > "checked_set", which tests the setting or aborts. > > > > Regards, > > Andreas" > > > > Am 18.02.19 um 15:06 schrieb workbe...@gmx.at: > > > > > > Hi everyone, > > > > > > i've looked the web but found no result. I need a string variable > > > that > > > allows only certain values, like bool variables only allow > > > true/false > > > my string should be either "A" or "B" ... > > Is this a cache variable or a regular variable? Cache variables have > this enum-like support in the form of the STRINGS property. Example: > > set(MYSTRING "A" CACHE STRING "Documentation for the variable") > set_property(CACHE MYSTRING PROPERTY STRINGS "A;B") > Note that this isn't an enforcing feature, only a convenience for CMake GUI and ccmake. It tells those tools what to show as selectable options for that cache variable, but you can still set the variable to anything you like via the cmake -D command line option or in the project itself. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] requiring parallel building but sequential linking
On Mon, Feb 18, 2019 at 9:35 AM Domen Vrankar wrote: > Hi, > > I'm building llvm project with CMake. > While build process is compiling the code I prefer running "make -j3" on > my 4 core pc (bumping processor to 100% on 3 of 4 cores and using up ~5 GB > of ram - part of it is system and not build related). > While build process is linking I must run "make" with a single job because > otherwise I run out of memory (cores do little work but ram usage goes past > 23 GB). > > Currently I'm handling this so that I first run "make -j3" and once I get > to about 90% (first larger linking) I hit ctrl+c and run "make". > > Is there a feature in CMake that would support handling this transition of > parallel builds, sequential linking out of the box? > (while I'm mostly interested in Linux/make support, having the same > feature for Windows/nmake/ninja through the same command line cmake command > would be even better) > This is available for Ninja with the JOB_POOL_LINK <https://cmake.org/cmake/help/latest/prop_tgt/JOB_POOL_LINK.html> target property, the default for which can be set project-wide with the CMAKE_JOB_POOL_LINK <https://cmake.org/cmake/help/latest/variable/CMAKE_JOB_POOL_LINK.html> variable. You can control the number of parallel jobs for a given pool with the JOB_POOLS <https://cmake.org/cmake/help/latest/prop_gbl/JOB_POOLS.html> global property. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Feedback CMAKE bug in VS2017 WDK for Windows 10, version 1809
On Sat, Feb 16, 2019 at 4:44 PM 啊啊啊 wrote: > If VS2017 WDK for Windows 10, version 1809 is installed, CMAKE will report > an error and display an error. The C CXX compiler identification is > unknown. After investigation, it is because WDK.VISX in WDK caused this > problem. Uninstalling this extension cmake returns to normal, but wdk will > not work. I hope to check the cause of the C CXX compiler identification is > unknown and fix it. Let cmake work with WDK at the same time. > > working environment > VS2017 15.97 > WDK for Windows 10, version 1809 > WIN10 PRO > > Uninstalling the VS extension of the WDK, CMAKE can work normally, as long > as the VS extension of the WDK is installed, cmake reports that the C CXX > compiler is unknown. > This seems very similar to an issue recently reported here: https://gitlab.kitware.com/cmake/cmake/issues/18920 -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Redundant linking when modifying shared libraries
On Thu, Feb 14, 2019 at 9:24 PM Itay Chamiel wrote:
> Hi,
>
> I've asked this question on Stack Overflow almost a year ago with no
> useful responses (with the same topic if you wish to search for it), so I'm
> trying my luck here.
>
> I work on a large commercial C++ project comprised of a couple dozen
> dynamically linked shared libraries, each of which has many associated unit
> tests. Many libs are also dependent on other libs because a lib for some
> specific functionality will use the code from one of the more common libs.
> And finally of course there are the production executables which depend on
> the libs.
>
> There is no question that a change in the API (a header file) of some core
> common lib should trigger a major recompilation of nearly the entire
> system. But typically there is only a change in some function's
> implementation, and the only file compiled is the modified .cpp file, and
> in theory just the modified lib would need to be linked - thanks to dynamic
> linking there should be no need to relink anything else. But CMake goes
> ahead and does it anyway: after relinking the lib it relinks all the unit
> tests associated with that lib. Then it relinks all the libs in that lib's
> dependency tree and all their unit tests. Finally it relinks the production
> executables. Due to the scale of the project this takes a lot of precious
> time.
>
> I have reproduced this behavior with a simple project based on the example
> at cmake.org/examples (comments removed for brevity and lib type changed
> to shared). My system is Ubuntu 16 on an Intel PC and my CMake version is
> 3.5.1.
>
> Start with an empty directory. Create subdirectories Demo and Hello and
> then create these files:
>
> * CMakeLists.txt
>
> cmake_minimum_required (VERSION 2.8.11)
> project (HELLO)
> add_subdirectory (Hello)
> add_subdirectory (Demo)
>
> * Demo/CMakeLists.txt
>
> add_executable (helloDemo demo.cpp)
> target_link_libraries (helloDemo LINK_PUBLIC Hello)
>
> * Demo/demo.cpp
>
> #include "hello.h"
> int main() { hello(); }
>
> * Hello/CMakeLists.txt
>
> add_library (Hello SHARED hello.cpp)
> target_include_directories (Hello PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
>
> * Hello/hello.h
>
> void hello();
>
> * Hello/hello.cpp
>
> #include
> void hello() { printf("hello!\n"); }
>
> * now run the commands:
>
> mkdir build
> cd build
> cmake ../
> make
>
> * You may now execute Demo/helloDemo and see hello!.
>
> Now, touch Hello/hello.cpp and make again. You will see that libHello is
> built and linked as expected, but then the helloDemo executable is also
> relinked ("Linking CXX executable helloDemo"). The latter step is
> completely redundant; even if hello.cpp is modified to print a different
> string the relinked executable remains binary identical.
>
> Is there a way to prevent these redundant build actions? This would be a
> huge time saver for us.
>
I think you might be looking for the LINK_DEPENDS_NO_SHARED
<https://cmake.org/cmake/help/latest/prop_tgt/LINK_DEPENDS_NO_SHARED.html>
target
property (or more likely its associated CMAKE_LINK_DEPENDS_NO_SHARED
<https://cmake.org/cmake/help/latest/variable/CMAKE_LINK_DEPENDS_NO_SHARED.html>
variable).
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Shared library under Windows and CMake: DLL not found before installation
On Thu, Feb 7, 2019 at 7:11 AM Brad King via cmake-developers <
cmake-developers@cmake.org> wrote:
> On 2/6/19 2:40 PM, Joachim Wuttke wrote:
> > And combine it with
> >
> > ```
> > link_directories(BEFORE ${PROJECT_BINARY_DIR}/bin)
> > ```
> >
> > so that tests find the libraries?
>
> No. CMAKE_RUNTIME_OUTPUT_DIRECTORY only affects the locations of
> the .dll files, not .a/.so/.lib. Also CMake already knows where
> the library files will be and links via absolute path. Link
> directories are almost never needed.
>
> > Anyway, my problem is not at link time, but when _executing_ a test.
> > Is there a canonical way of manipulating the Windows PATH from CMake?
>
> No. In general one should not depend on PATH for .dll locations
> within your own project.
>
That's probably a bit strong, for very large projects it can be quite
inconvenient to have to put all executables and DLLs in the same directory.
For some scenarios, it's not a viable choice (can depend on the project's
directory layout requirements). There are a few ways to get this to work
for different scenarios, some depending on a more recent CMake version. For
tests run through CTest, The ENVIRONMENT test property can be used to
augment PATH on a test-by-test basis. For running under the Visual Studio
debugger, CMake 3.13 added the VS_DEBUGGER_ENVIRONMENT target property
which again can be used to set the PATH for a particular test executable
when run from within the VS IDE. If you need to support an older CMake
version, an equivalent functionality can be achieved with CMake 3.8 or
later using the VS_USER_PROPS target property, but this is more involved.
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12
I don't know if it is an option in your case, but you could build boost yourself as static libraries. Then the whole build/install rpath situation goes away. In case it is helpful, I recently gave an example of how I'm currently doing this with a FetchContent-based solution. It won't suit everyone, but the approach might be relevant for your particular case. https://gitlab.kitware.com/cmake/cmake/issues/18831#note_509194 On Wed, Feb 6, 2019 at 9:00 AM Stephens, J. Adam via CMake wrote: > Hi Robert, > > Thanks for your reply. We do use install_name_tool and the like when > installing/packaging, and our packages continue to work fine on OS X 10.12. > My question is about what to do with executables before packaging, while > they are still just in the build tree. We need them to work for purposes of > testing via CTest. > > Adam > > > On 2/5/19, 2:56 PM, "Robert Maynard" wrote: > > My general approach for the second problem is to run a tool such as > install_name_tool to change the library names to have @rpath when > constructing the package. > > On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake > wrote: > > > > Hello, > > > > > > > > The project I work on links to several shared boost libraries. After > our organization disallowed use of OS X 10.11 and we upgraded our > built/test slave to 10.12, we encountered a problem with our testing. > Executables in the build tree that were built as part of our project now > fail to run with the error that boost libraries can’t be found. > > > > > > > > Superficially, the problem is that (I think) Apple strengthened the > SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any > effect – previously the linker was able to locate the boost libs for our > build tree executables that way. > > > > > > > > The deeper problem is twofold: First, the build tree executables > don’t include the boost lib folder in their RPATHs. Second, the install > names embedded in boost libs themselves are just the bare filenames with no > @rpath. (My understanding is, the boost project does that deliberately > because they can’t know what users of their libraries will want.) > > > > > > > > Recent versions of CMake (3.8+) have the property BUILD_RPATH that > we could use to embed the path to the boost libs into the build tree > executables. That doesn’t solve the second part of the problem, though. > Without embedding install names that look like @rpath/libboost_foo.dylib in > the build tree executables, I think the linker will still be unable to find > them. > > > > > > > > What is the best (or least bad) way to fix this? > > > > > > > > Thanks! > > > > > > > > Adam > > > > > > > > -- > > > > J. Adam Stephens, Ph.D. > > > > Dakota Support Analyst > > > > https://dakota.sandia.gov/ > > > > Optimization and UQ > > > > Sandia National Laboratories > > > > Albuquerque, NM > -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Checking Variables in a tool-chain file
This is precisely the scenario that the CMAKE_TRY_COMPILE_PLATFORM_VARIABLES
<https://cmake.org/cmake/help/latest/variable/CMAKE_TRY_COMPILE_PLATFORM_VARIABLES.html>
variable
is meant for. It allows a toolchain file to specify additional variables
that should be passed along to try_compile().
On Fri, Feb 1, 2019 at 6:36 AM Shoaib Meenai wrote:
> We have a somewhat similar problem with LLVM's toolchain file for
> cross-compiling to Windows, and we solve it there by saving and restoring
> cache variables from the environment inside the toolchain file itself. See
> https://reviews.llvm.org/diffusion/L/browse/llvm/trunk/cmake/platforms/WinMsvc.cmake;352783$88-102?as=source=off
> and the subsequent calls to init_user_prop.
>
> On 1/31/19, 12:19 AM, "CMake on behalf of tors...@robitzki.de" <
> cmake-boun...@cmake.org on behalf of tors...@robitzki.de> wrote:
>
> Hi Sergei,
>
> > Am 31.01.2019 um 08:42 schrieb Sergei Nikulov <
> sergey.niku...@gmail.com>:
> >
> > Just guessing maybe better use $ENV{ARM_GCC_TOOL_PATH} ?
> > https://cmake.org/cmake/help/latest/variable/ENV.html?highlight=env
>
> Well, but this would mean, I had to configure CMake not only with
> Cache variables:
>
> cmake
> -DARM_GCC_TOOL_PATH=/usr/local/gcc-arm-none-eabi-7-2018-q2-update
> -DBINDING=nrf52 -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi.cmake
> -DNRF5_SDK_ROOT=~/CMSIS/nRF5_SDK_14-2/ ..
>
> But also with environment variables:
> ARM_GCC_TOOL_PATH=/usr/local/gcc-arm-none-eabi-7-2018-q2-update cmake
> -DBINDING=nrf52 -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi.cmake
> -DNRF5_SDK_ROOT=~/CMSIS/nRF5_SDK_14-2/ ..
>
> Thanks for the pointer, I will think about it.
>
> kind regards,
> Torsten
>
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Modern cmake advise for transitive library dependencies
On Wed, Dec 19, 2018 at 5:36 AM Alan W. Irwin wrote: > On 2018-12-17 21:35+0100 Mario Emmenlauer wrote: > > > > > Dear cmake team and user community, > > > > I'd kindly like to ask for advice on how to handle transitive > > dependencies cleanly with "modern" cmake. I'm often plagued by this > > problem: I have a library X that optionally depends on library A. > > When I build library Y that depends on X, how do I (cleanly) handle > > the optional dependency A? > > Assume "A" would be "Qt5Core". I can link X publicly against Qt5::Core. > > But when I import X into Y, then Y will complain about unknown target > > Qt5::Core, unless I do find_package(Qt5 COMPONENTS Core) in Y. But since > > Qt is optional in X, I would need to track somehow if Qt was enabled > > before. > > > > But what good is the public transitive dependency when I manually need > > to track it, to find the libraries again? Am I missing something? > > Can the dependency be automatically resolved, or can I query some > > variable if X was linking A? > > > > How to do this cleanly? > > Hi Mario: > > One way to cleanly automate this is to configure the XConfig.cmake > file (depending on whether X is linked with Qt5 or not) to optionally > execute > > find_package(Qt5 ...) > > As a result, when the logic in XConfig.cmake is executed as a result of > > find_package(X ...) > > from Y, Qt5 should be found automatically when needed. > Your XConfig.cmake is responsible for also ensuring all targets it depends on are defined. This shouldn't be left up to consumers of X. The way this is normally done is pretty much as Alan suggests (it's also the way I handle cases analogous to yours in our projects at work). There's even a find_dependency() <https://cmake.org/cmake/help/latest/module/CMakeFindDependencyMacro.html> command intended for precisely this situation to make it a little easier, although I generally advise against using it for packages that support components due to the way a particular optimisation in its implementation affects later find_dependency() calls for the same package. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 3.11.3: set properties on the command line?
On Tue, Dec 18, 2018 at 7:42 AM Paul Smith wrote: > Hi all. > > I'm using cmake with a cross-compiler environment, but building third > party packages that are configured with CMake. So when I invoke cmake > for those packages I add this options to the command line: > > -DCMAKE_FIND_ROOT_PATH=/my/sysroot > > However, this is not working because it's finding 32bit libraries. For > example if the package's CMakeLists.txt file contains this: > > find_package(ZLIB REQUIRED) > > then my link line ends up containing: > > /my/sysroot/usr/lib/libz.so > > which is the 32bit version and the link fails. The 64bit version DOES > exist exactly as it should: > > $ ls -1 /my/sysroot/usr/lib*/libz.so* > /my/sysroot/tools/usr/lib/libz.so > /my/sysroot/tools/usr/lib64/libz.so > > and the link works if I do it by hand with the right path. I don't > know why it's not automatically looking for lib64; I checked and CMake > knows I want a 64bit build. For example I see this after running: > > CMakeFiles/3.11.3/CMakeCXXCompiler.cmake:set(CMAKE_CXX_SIZEOF_DATA_PTR > "8") > > Actually I wish cmake would just add "-lz" to the command line and let > the linker figure it all out rather than trying to second-guess things. > Then it would "just work". > > In any event, if I edit the CMakeLists.txt in the package to set the > global property FIND_LIBRARY_USE_LIB64_PATHS to ON, then it all works > fine: > > set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON) > > But I can't see any way to set that property from the command line, > without editing the package's CMakeLists.txt file which I obviously > don't want to do. > > Help for either (a) figuring out why cmake incorrectly chooses 32bit > libraries or (b) setting the property without editing third-party > CMakeLists.txt files would be much appreciated!! > If you are setting your own sysroot, are you using a toolchain file? You could put your set_property() command in your toolchain file if you're using one. If you're not using a toolchain file and don't want to go that route, you could potentially inject the commands you want using the CMAKE_PROJECT__INCLUDE <https://cmake.org/cmake/help/latest/variable/CMAKE_PROJECT_PROJECT-NAME_INCLUDE.html> feature. It allows you to effectively include a file immediately after a project() command without having to actually edit the CMakeLists.txt that contains that project() command. Those techniques aside, it's interesting that you need to add this manual workaround at all. I suspect this code <https://gitlab.kitware.com/cmake/cmake/blob/v3.13.2/Modules/Platform/Linux.cmake#L55> might be why it is being turned off for you, but without more detail about your build setup, it's hard to say. If you use a toolchain file and set CMAKE_SYSTEM_NAME to anything (even the same as the CMAKE_HOST_SYSTEM_NAME), CMAKE_CROSSCOMPILING will be TRUE, which I suspect would prevent the problem you're seeing. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] How to set CTEST_BUILD_NAME
On Mon, Dec 17, 2018 at 6:41 AM Donald MacQueen [|] <
dm...@instantiations.com> wrote:
> I want to do something like set(CTEST_BUILD_NAME
> {CMAKE_SYSTEM_NAME}_someLocalVariable)
>
> I tried putting this ^^ in CTestConfig.cmake with no luck.
>
> I searched the docs and the archives from 2014 to the present and
> nothing jumped out at me.
>
> 2) Is there a list of what can be set/used in CTestConfig.cmake?
>
The variables are not all collected together conveniently, but the Dashboard
Client section
<https://cmake.org/cmake/help/latest/manual/ctest.1.html#dashboard-client-configuration>
of the ctest command does list the supported variables associated with each
command. It would seem like setting CTEST_BUILD_NAME should work based on
those docs, so perhaps if you could point us as a minimal complete example
which demonstrates your problem, that might give more clues as to what's
happening for you.
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Correct way to specify multiple build configurations for single config generators?
On Mon, Dec 10, 2018 at 1:37 PM Zaak Beekman wrote: > I have been reading the *excellent* book "Professional CMake". The author, > Craig Scott, recommends the following best practices: > >- check the existence of `CMAKE_CONFIGURATION_TYPES` and only adding >or pruning configurations if it's preset, *AFTER* your call to `project()` >- do not set `CMAKE_CONFIGURATION_TYPES` and use the `STRINGS` >property on `CMAKE_BUILD_TYPE` for single config generators >- forcibly set the `CMAKE_BUILD_TYPE` cache variable if it is unset, >otherwise check the passed `CMAKE_BUILD_TYPE` against allowable configs and >throw an error if it differs >- set `CMAKE__FLAGS_` and >`CMAKE__LINKER_FLAGS_` variables as cache variables for >newly defined configuration > > The problem I encounter is that, if I set > `-DCMAKE_BUILD_TYPE:STRING=` to CMake on the command line, then > CMake seems to initialize all of the `` cache variables to the > empty string *BEFORE* I can set them. All other custom configurations get > set to my specified default cache variable value. > > What is the best practice for setting the new configuration's default > flags? > This is only going to be an issue for single-configuration generators. For multi-config generators, you don't set CMAKE_BUILD_TYPE and the flags you set as cache variables after the first project() call should be honoured. For single-config generators, you have a few choices: - Run CMake with CMAKE_BUILD_TYPE set to some other config first, then change it to the one you want after the first run. If the custom config is one that is only occasionally used and typically just one you switch to temporarily from time-to-time, then this may be okay for your situation. It's also easy enough to handle in a CI build, albeit slightly less efficient since you have to run CMake twice. It's a bit annoying, but it is at least easy. - Rather than setting the custom config's flags in the project, do it in a toolchain file instead (with the various ...__INIT variables). The flags are going to be toolchain-specific anyway, so you don't lose generality. You also gain the advantage that you can take that same toolchain file and apply it to other projects, so you get better reusability. This would be what I would use personally, but I'm comfortable with toolchain files. The main downside to this approach is that those new to CMake can feel a bit intimidated by toolchain files or see them as an unnecessary complication for a build that should just pick up the default compilers and work out of the box. It's a tradeoff, so I erred on the side of simplicity in the book and didn't make toolchains a recommendation for defining custom configs. If you and your users are happy with toolchain files though, I'd go this route. - You could set your custom config's cache variables (again I'd recommend setting the ...__INIT variables) before the first project() command, but you won't have the compiler ID or any other compiler information at that point. You also won't have any of the default configs' flags available to you, so you can't make your custom config an extension of an existing one (e.g. you can't start with flags from, say, RelWithDebInfo and add a few more to enable profiling like in the book's example). If your project only needs to consider one compiler and the flags are simple and well-defined, this is going to be the easiest for your developers, since it will work out-of-the-box with no extra effort on their part. - Instead of setting cache variables, you could append to regular non-cache ... variables after the project() command. This has the advantage of being simple, but your config-specific flags won't show in the cache and developers can't override them without editing the project. So as you can see from the above, there's no one perfect solution. The best choice really depends on your project and your users. > > I am aware of `CMAKE_USER_MAKE_RULES_OVERRIDE` and all of the > `CMAKE__FLAGS__INIT` variable, but as far as I > can tell, there is no access to knowing what compiler is being used, since > the compilers have yet to be probed. Is it possible to use the > `CMAKE_..._INIT` variables to set per-compiler flags some how? > Use a toolchain file where you are in control of which compiler is selected. Use different toolchain files for different compilers. > Any answers or pointers here would be most appreciated. > > FYI, Before being enlightened to some of the dangers or non-standard ways > of what I was doing, I would typically set `CMAKE_CONFIGURATION_TYPES` > *before* my call to `project()`. Something like this: > > ```cmake > set ( CMAKE_CONFIGURATION_TYPES "Debug" "Release" "MinSizeRel&quo
Re: [CMake] dependencies of cross compiliations
On Mon, Dec 10, 2018 at 7:57 PM Eric Noulard wrote: > > Le dim. 9 déc. 2018 à 12:24, Craig Scott a > écrit : > >> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki >> wrote: >> >>> > Am 27.11.2018 um 19:55 schrieb Eric Noulard : >>> > >>> > My assumption are: >>> > a) when you cross-compile your build is a "whole" and you shouldn't >>> have to setup some superbuild >>> >structure for building host tools ht_exe and another for target1 >>> tool t1t_exe and another one for target2 tool t2t_exe. >>> > >>> > b) what you want is to build: >>> > ht_exe for the host >>> > possibly use ht_exe during the build to generate some [source] >>> file >>> > t1t_exe for the [cross]target1 >>> > t2t_exe for the [cross]target2 >>> > >>> > c) you seldomly compile the same source for the host AND the target, >>> but it may happen. >>> >>> In case, you are doing unit tests, it’s normal to have the same code >>> running in a test on the host platform and in the final binary on the >>> target. >>> >>> I think, having more than 1 target platform becomes more and more normal >>> as it becomes more usual to have multiple microcontrollers in a project. >>> >> > Yes that's why I thought it was worth going further than host + target, > but host + tgt1 + tg2 + > > >> >>> Previously, I have encoded this in the build type. So instead of just >>> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug, >>> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very >>> much, that I have to run CMake 3 times to get all the binaries for a >>> release build. The problem that I have, are dependencies between this >>> builds. If I write a tool that (for example) generates source files for one >>> of the target platforms, the build for the host platform must run before >>> the build for that target platform. And when I make changes to that tool, I >>> want the build to regenerate the generated source files. >>> >>> Keeping track of this dependencies to solve this kind of ordering issues >>> and to allow minimum rebuilds, is the main purpose of any build system. To >>> solve this with CMake, I think we need a way to define the dependencies >>> between build types (in the example above, from the generator from the host >>> build to the generated source file in one of the target builds) and CMake >>> needs to know the build directory for all build types (not only the >>> current). >>> >> >> Perhaps a superbuild would be the cleanest approach here? The host tools >> would be one subproject and the cross-compile builds would depend on the >> host tools' build. You could then choose to build everything via the top >> level superbuild or just work on one of the subprojects if that's all you >> needed once the initial tools build had been done. You could even set up as >> many different sub-projects for the different architectures as needed. >> Packaging would require a little more work, but it shouldn't be >> prohibitively so. >> > > I guess the tough part is to find a [light] way to specify dependencies > between host target build and the various target builds. > > >> Another alternative is the approach described in this stackoverflow >> article >> <https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run> >> which performs the host tools build off to the side in a secondary build >> during configure. This works well when the host tools don't change much (we >> use it extensively at work with very large, complex hierarchical projects). >> It wouldn't help though if you need to build more than one cross-compiled >> architecture. >> >> > The wish-season is coming up, so that's sort of what I would like to >>> > have. Now it's your turn. No bikeshedding please, only deliveries ;) >>> >>> How about ``add_dependencies()`` allowing me to define dependencies >>> between different build types? :-) >>> >> >> A superbuild would already give you the equivalent capability. >> > > Not as easy as it seems right? > I bet you know it well as you listed the dependencies shortcoming of > adding dependencies for External_ProjectAdd in your book (§27.1.4). > For a strict superbuild arrangement, handling straight dependencies to get build orde
Re: [cmake-developers] [CMake] dependencies of cross compiliations
On Mon, Dec 10, 2018 at 7:57 PM Eric Noulard wrote: > > Le dim. 9 déc. 2018 à 12:24, Craig Scott a > écrit : > >> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki >> wrote: >> >>> > Am 27.11.2018 um 19:55 schrieb Eric Noulard : >>> > >>> > My assumption are: >>> > a) when you cross-compile your build is a "whole" and you shouldn't >>> have to setup some superbuild >>> >structure for building host tools ht_exe and another for target1 >>> tool t1t_exe and another one for target2 tool t2t_exe. >>> > >>> > b) what you want is to build: >>> > ht_exe for the host >>> > possibly use ht_exe during the build to generate some [source] >>> file >>> > t1t_exe for the [cross]target1 >>> > t2t_exe for the [cross]target2 >>> > >>> > c) you seldomly compile the same source for the host AND the target, >>> but it may happen. >>> >>> In case, you are doing unit tests, it’s normal to have the same code >>> running in a test on the host platform and in the final binary on the >>> target. >>> >>> I think, having more than 1 target platform becomes more and more normal >>> as it becomes more usual to have multiple microcontrollers in a project. >>> >> > Yes that's why I thought it was worth going further than host + target, > but host + tgt1 + tg2 + > > >> >>> Previously, I have encoded this in the build type. So instead of just >>> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug, >>> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very >>> much, that I have to run CMake 3 times to get all the binaries for a >>> release build. The problem that I have, are dependencies between this >>> builds. If I write a tool that (for example) generates source files for one >>> of the target platforms, the build for the host platform must run before >>> the build for that target platform. And when I make changes to that tool, I >>> want the build to regenerate the generated source files. >>> >>> Keeping track of this dependencies to solve this kind of ordering issues >>> and to allow minimum rebuilds, is the main purpose of any build system. To >>> solve this with CMake, I think we need a way to define the dependencies >>> between build types (in the example above, from the generator from the host >>> build to the generated source file in one of the target builds) and CMake >>> needs to know the build directory for all build types (not only the >>> current). >>> >> >> Perhaps a superbuild would be the cleanest approach here? The host tools >> would be one subproject and the cross-compile builds would depend on the >> host tools' build. You could then choose to build everything via the top >> level superbuild or just work on one of the subprojects if that's all you >> needed once the initial tools build had been done. You could even set up as >> many different sub-projects for the different architectures as needed. >> Packaging would require a little more work, but it shouldn't be >> prohibitively so. >> > > I guess the tough part is to find a [light] way to specify dependencies > between host target build and the various target builds. > > >> Another alternative is the approach described in this stackoverflow >> article >> <https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run> >> which performs the host tools build off to the side in a secondary build >> during configure. This works well when the host tools don't change much (we >> use it extensively at work with very large, complex hierarchical projects). >> It wouldn't help though if you need to build more than one cross-compiled >> architecture. >> >> > The wish-season is coming up, so that's sort of what I would like to >>> > have. Now it's your turn. No bikeshedding please, only deliveries ;) >>> >>> How about ``add_dependencies()`` allowing me to define dependencies >>> between different build types? :-) >>> >> >> A superbuild would already give you the equivalent capability. >> > > Not as easy as it seems right? > I bet you know it well as you listed the dependencies shortcoming of > adding dependencies for External_ProjectAdd in your book (§27.1.4). > For a strict superbuild arrangement, handling straight dependencies to get build orde
Re: [cmake-developers] [CMake] dependencies of cross compiliations
On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki wrote: > > Am 27.11.2018 um 19:55 schrieb Eric Noulard : > > > > However from my point of view and my cross-compiling experience when you > cross-compile you have: > > > > 1) the host compiler which is used to compile "host tools" > > 2) the target compiler (may be several of them) to "cross-compile" > > > > My assumption are: > > a) when you cross-compile your build is a "whole" and you shouldn't > have to setup some superbuild > >structure for building host tools ht_exe and another for target1 tool > t1t_exe and another one for target2 tool t2t_exe. > > > > b) what you want is to build: > > ht_exe for the host > > possibly use ht_exe during the build to generate some [source] file > > t1t_exe for the [cross]target1 > > t2t_exe for the [cross]target2 > > > > c) you seldomly compile the same source for the host AND the target, > but it may happen. > > In case, you are doing unit tests, it’s normal to have the same code > running in a test on the host platform and in the final binary on the > target. > > I think, having more than 1 target platform becomes more and more normal > as it becomes more usual to have multiple microcontrollers in a project. > > Previously, I have encoded this in the build type. So instead of just > having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug, > NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very > much, that I have to run CMake 3 times to get all the binaries for a > release build. The problem that I have, are dependencies between this > builds. If I write a tool that (for example) generates source files for one > of the target platforms, the build for the host platform must run before > the build for that target platform. And when I make changes to that tool, I > want the build to regenerate the generated source files. > > Keeping track of this dependencies to solve this kind of ordering issues > and to allow minimum rebuilds, is the main purpose of any build system. To > solve this with CMake, I think we need a way to define the dependencies > between build types (in the example above, from the generator from the host > build to the generated source file in one of the target builds) and CMake > needs to know the build directory for all build types (not only the > current). > Perhaps a superbuild would be the cleanest approach here? The host tools would be one subproject and the cross-compile builds would depend on the host tools' build. You could then choose to build everything via the top level superbuild or just work on one of the subprojects if that's all you needed once the initial tools build had been done. You could even set up as many different sub-projects for the different architectures as needed. Packaging would require a little more work, but it shouldn't be prohibitively so. Another alternative is the approach described in this stackoverflow article <https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run> which performs the host tools build off to the side in a secondary build during configure. This works well when the host tools don't change much (we use it extensively at work with very large, complex hierarchical projects). It wouldn't help though if you need to build more than one cross-compiled architecture. > > The wish-season is coming up, so that's sort of what I would like to > > have. Now it's your turn. No bikeshedding please, only deliveries ;) > > How about ``add_dependencies()`` allowing me to define dependencies > between different build types? :-) > A superbuild would already give you the equivalent capability. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] dependencies of cross compiliations
On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki wrote: > > Am 27.11.2018 um 19:55 schrieb Eric Noulard : > > > > However from my point of view and my cross-compiling experience when you > cross-compile you have: > > > > 1) the host compiler which is used to compile "host tools" > > 2) the target compiler (may be several of them) to "cross-compile" > > > > My assumption are: > > a) when you cross-compile your build is a "whole" and you shouldn't > have to setup some superbuild > >structure for building host tools ht_exe and another for target1 tool > t1t_exe and another one for target2 tool t2t_exe. > > > > b) what you want is to build: > > ht_exe for the host > > possibly use ht_exe during the build to generate some [source] file > > t1t_exe for the [cross]target1 > > t2t_exe for the [cross]target2 > > > > c) you seldomly compile the same source for the host AND the target, > but it may happen. > > In case, you are doing unit tests, it’s normal to have the same code > running in a test on the host platform and in the final binary on the > target. > > I think, having more than 1 target platform becomes more and more normal > as it becomes more usual to have multiple microcontrollers in a project. > > Previously, I have encoded this in the build type. So instead of just > having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug, > NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very > much, that I have to run CMake 3 times to get all the binaries for a > release build. The problem that I have, are dependencies between this > builds. If I write a tool that (for example) generates source files for one > of the target platforms, the build for the host platform must run before > the build for that target platform. And when I make changes to that tool, I > want the build to regenerate the generated source files. > > Keeping track of this dependencies to solve this kind of ordering issues > and to allow minimum rebuilds, is the main purpose of any build system. To > solve this with CMake, I think we need a way to define the dependencies > between build types (in the example above, from the generator from the host > build to the generated source file in one of the target builds) and CMake > needs to know the build directory for all build types (not only the > current). > Perhaps a superbuild would be the cleanest approach here? The host tools would be one subproject and the cross-compile builds would depend on the host tools' build. You could then choose to build everything via the top level superbuild or just work on one of the subprojects if that's all you needed once the initial tools build had been done. You could even set up as many different sub-projects for the different architectures as needed. Packaging would require a little more work, but it shouldn't be prohibitively so. Another alternative is the approach described in this stackoverflow article <https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run> which performs the host tools build off to the side in a secondary build during configure. This works well when the host tools don't change much (we use it extensively at work with very large, complex hierarchical projects). It wouldn't help though if you need to build more than one cross-compiled architecture. > > The wish-season is coming up, so that's sort of what I would like to > > have. Now it's your turn. No bikeshedding please, only deliveries ;) > > How about ``add_dependencies()`` allowing me to define dependencies > between different build types? :-) > A superbuild would already give you the equivalent capability. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] [MSVC] Setting warning level on target feels like long-time bug
>From what I understand from a very limited quick search just now, it seems
that /W3 is the default warning level for Visual Studio (according to
the Microsoft
docs
<https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2017>),
but CMake explicitly adds it
<https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Platform/Windows-MSVC.cmake#L360>
as a default compiler flag in CMAKE__FLAGS_INIT. This makes me wonder
if it has always been the default, otherwise it isn't clear why it was
deemed necessary to add it. More to the point, unless there's a reason not
to, perhaps we could consider removing it from the default flags CMake
sets. I think this would largely address the situation you're describing
and shouldn't actually change the behavior of existing projects. I've CC'ed
the developer's list and suggest that follow-up discussion should occur
there.
On Sun, Dec 9, 2018 at 8:07 AM Mateusz Loskot wrote:
> Hi,
>
> I define a target for a library, and set warning level for MSVC compiler:
>
> target_compile_options(mylib PRIVATE $<$:-W4>)
>
> Although this works well, the compiler throws this warning:
>
> cl : Command line warning D9025: overriding '/W3' with '/W4'
>
> I want to get rid of this warning, so I fix it this way
>
> if(MSVC)
> string(REGEX REPLACE "/W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
> string(REGEX REPLACE "-W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
> endif()
>
> target_compile_options(mylib PRIVATE $<$:-W4>)
>
> This works like charm, but leaves me with sour feeling that
> something is not right here.The REGEX REPLACE clean-up
> has become such a habit, it's almost canonical thing I do in
> all my CMake-based projects.
>
> Shouldn't CMake drop the default when target_compile_options is called?
> Is this behaviour by design, for MSVC?
> Could anyone help me to understand if this is actually a bug
> or am I misunderstanding anything?
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
>
> 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
>
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug
>From what I understand from a very limited quick search just now, it seems
that /W3 is the default warning level for Visual Studio (according to
the Microsoft
docs
<https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2017>),
but CMake explicitly adds it
<https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Platform/Windows-MSVC.cmake#L360>
as a default compiler flag in CMAKE__FLAGS_INIT. This makes me wonder
if it has always been the default, otherwise it isn't clear why it was
deemed necessary to add it. More to the point, unless there's a reason not
to, perhaps we could consider removing it from the default flags CMake
sets. I think this would largely address the situation you're describing
and shouldn't actually change the behavior of existing projects. I've CC'ed
the developer's list and suggest that follow-up discussion should occur
there.
On Sun, Dec 9, 2018 at 8:07 AM Mateusz Loskot wrote:
> Hi,
>
> I define a target for a library, and set warning level for MSVC compiler:
>
> target_compile_options(mylib PRIVATE $<$:-W4>)
>
> Although this works well, the compiler throws this warning:
>
> cl : Command line warning D9025: overriding '/W3' with '/W4'
>
> I want to get rid of this warning, so I fix it this way
>
> if(MSVC)
> string(REGEX REPLACE "/W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
> string(REGEX REPLACE "-W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
> endif()
>
> target_compile_options(mylib PRIVATE $<$:-W4>)
>
> This works like charm, but leaves me with sour feeling that
> something is not right here.The REGEX REPLACE clean-up
> has become such a habit, it's almost canonical thing I do in
> all my CMake-based projects.
>
> Shouldn't CMake drop the default when target_compile_options is called?
> Is this behaviour by design, for MSVC?
> Could anyone help me to understand if this is actually a bug
> or am I misunderstanding anything?
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
>
> 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
>
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] Effective CMake - warning on bad practices
On Fri, Nov 23, 2018 at 11:07 PM cen wrote:
> I finished watching "Effective CMake" talk by Daniel Pfeifer from last
> year and it seems to me it is the "GO TO" resource for best practices. A
> quick scan of my CMakeLists.txt files and sure enough, I use
> include_directories() and other "dont's". The problem is that none of
> the things mentioned in the talk:
>
> a) give any warnings when running cmake
>
> b) are mentioned as bad practice in the docs
>
>
> What I would prefer is that everytime a bad practice is used a big red
> warning would be printed by CMake so I could see it and correct it.
>
> Since CMake is apparently very slow deprecating things a solution
> appeared in my mind after seeing the function wrap functionality. How
> about a file called Effective.cmake which contains something like
> (pseudocode):
>
> function(include_directories input output)
>
> message(DEPRECATION "Use target_include_directories() instead."
>
> _include_directories(...)
>
> endfunction()
>
> function(set input output)
>
> if (${ARG0} STREQUAL "CMAKE_CXX_FLAGS")
>
> message(DEPRECATION "You probably shouldn't use this directly")
>
> endif
>
> _set(...)
>
> endfunction()
>
> ...
>
>
> then include(Effective.cmake) in your CMakeLists.txt to enable all
> warnings. The effort here is to compile a list of existing bad practices
> and wrap them (if such a thing is possible).
>
>
> Does this approach seem reasonable? Is there an effort with similar
> goals out in the wild which I should know about?
>
I would strongly advise against overriding built-in commands. The use of
undocumented behavior to try to call the previous original implementation
is not robust and can lead to infinite recursion. See the following article
for an explanation of why:
https://crascit.com/2018/09/14/do-not-redefine-cmake-commands/
I'm not aware of any efforts currently underway to add such a feature to
CMake itself. I think there is certainly a growing interest among users for
this sort of capability though.
Regarding guidance in the official CMake docs, they do try to avoid being
too opinionated, but things that are formally deprecated are usually
documented as such. Some commands still have their uses, even if they
should mostly be avoided, so they don't get the deprecation treatment.
Contributions to improve the docs are always welcome (and a big shout-out
to Joachim Wuttke who has been putting in a great effort lately in this
area).
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] add_library ALIAS
On Tue, Nov 20, 2018 at 1:20 AM rmawatson rmawatson
wrote:
> I am trying to figure out exactly what this line is for in the cmake file
> of the github json project here ->
> https://github.com/nlohmann/json/blob/develop/CMakeLists.txt#L48
>
> add_library(${PROJECT_NAME}::${NLOHMANN_JSON_TARGET_NAME} ALIAS
> ${NLOHMANN_JSON_TARGET_NAME})
>
> Specifically with this example, what does this allow in this cmake file
> that otherwise would not be possible?
>
It is to make incorporating the project into a larger project via
add_subdirectory() rather than via find_package() more
convenient/consistent. The latter relies on an installed package, which
will have been exported with the nlohmann_json:: namespace, so it will
provide imported targets with names like nlohmann_json::nlohmann_json. When
incorporating the project via add_subdirectory() instead, nothing is
exported, so targets like nlohmann_json::nlohmann_json won't exist unless
they are explicitly added as an ALIAS like in the example above.
In other words, ALIAS targets like this allow consuming projects to use the
same target name (nlohmann_json::nlohmann_json) regardless of how they
bring the json project in as a dependency.
> The commit message where this line was added says,
>
> "Enable target namespaces and build dir project config
>
> CMake convention is to use a project namespace, i.e. Foo::, for imported
> targets. When multiple targets are imported from a project, this looks
> like Foo::Bar1 Foo::Bar2, etc. This adds the nlohmann_json:: namespace to
> the exported target names.
>
> This also allows the generated project config files to be used from the
> build directory instead of just the install directory."
> Removing this line appears to make no difference to any off the generated
> cmake files. I can still use find_package with the build directory in
> CMAKE_PREFIX-PATH with our without this line. Has something changed in
> cmake since this was added?
>
The ALIAS won't change the exported files (because it isn't itself
installed/exported), it is only for use directly by a parent project
consuming it via add_subdirectory(). This is not a new feature, but it has
perhaps been discussed more openly in the past year or two. When the
FetchContent <https://cmake.org/cmake/help/latest/module/FetchContent.html>
module was added in CMake 3.11, it also became much easier to incorporate a
dependency via add_subdirectory().
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_OSX_SYSROOT icw iOS fat binaries (iPhone + iPhoneSimulator)
The IOS_INSTALL_COMBINED
<https://cmake.org/cmake/help/latest/prop_tgt/IOS_INSTALL_COMBINED.html> target
property allows you to create fat binaries, but only at install time. To
use this feature, set your CMAKE_OSX_SYSROOT to iphoneos and the simulator
slice will be built and added to the fat binary for you automatically
during the install step. If you require fat binaries at build time, that
could be much more challenging.
On Mon, Nov 19, 2018 at 10:19 PM Erik van Nooijen <
eric.vannooi...@tomtom.com> wrote:
> With CMake it is possible to build for fat binaries for iOS without
> XCode. Fat binaries meaning containing all the architectures for iPhone and
> iPhoneSimulator.
>
> However, when building frameworks, CMake builds it with the MacOSX layout,
> including '*Version*' directory and symlinks etc. This is wrong when
> building for iOS.
>
> The reason is that CMake determines bundle layout based on
> CMAKE_OSX_SYSROOT, but this cannot be set correctly in this situation, as
> it allows only one directory to be set, and we'd need two (iPhone and
> iPhoneSimulator). In short:
>
> * not setting CMAKE_OSX_SYSROOT results in MacOSX framework/bundle layouts
>
> * setting CMAKE_OSX_SYSROOT to a single sysroot gives error for the other
> architecture(s)
>
> ld: dynamic main executables must link with libSystem.dylib for
> architecture i386
>
> * setting CMAKE_OSX_SYSROOT to multiple sysroots gives error for incorrect
> paths
>
> Ignoring CMAKE_OSX_SYSROOT value:
>
>
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS10.1.sdk;/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator10.1.sdk
>
> because the directory does not exist.
>
>
>
> Please find below an example CMakeLists.txt to test/verify this. The
> behaviour can be switched on and off with the MAKE_FAT variable.
>
>
>
> What is the correct way to get fat binaries in the correct iOS layout in
> such a case?
>
>
>
> cmake_minimum_required(VERSION 3.13)
>
> project(iOSFatBinaries)
>
> set(MAKE_FAT TRUE)
>
>
>
> execute_process(COMMAND xcodebuild -version -sdk iphoneosPath
> COMMAND perl -ne "chomp;print;exit;" OUTPUT_VARIABLE SDK_IPHONE_ROOT)
>
> execute_process(COMMAND xcodebuild -version -sdk iphonesimulator Path
> COMMAND perl -ne "chomp;print;exit;" OUTPUT_VARIABLE
> SDK_IPHONE_SIMULATOR_ROOT)
>
>
>
> # CMAKE_OSX_ARCHITECTURES
>
> if(MAKE_FAT)
>
> set(CMAKE_OSX_ARCHITECTURES "armv7;armv7s;arm64;i386;x86_64" CACHE
> INTERNAL "Set supported OSX architectures")
>
> else()
>
> set(CMAKE_OSX_ARCHITECTURES "armv7;armv7s;arm64" CACHE INTERNAL "Set
> supported OSX architectures")
>
> endif()
>
>
>
> # CMAKE_C_FLAGS and CMAKE_CXX_FLAGS
>
> if(MAKE_FAT)
>
> set(SYSROOT_FLAGS " -arch armv7 -Xarch_armv7
> \"-isysroot${SDK_IPHONE_ROOT}\"")
>
> set(SYSROOT_FLAGS "${SYSROOT_FLAGS} -arch armv7s -Xarch_armv7s
> \"-isysroot${SDK_IPHONE_ROOT}\"")
>
> set(SYSROOT_FLAGS "${SYSROOT_FLAGS} -arch arm64 -Xarch_arm64
> \"-isysroot${SDK_IPHONE_ROOT}\"")
>
> set(SYSROOT_FLAGS "${SYSROOT_FLAGS} -arch i386 -Xarch_i386
> \"-isysroot${SDK_IPHONE_SIMULATOR_ROOT}\"")
>
> set(SYSROOT_FLAGS "${SYSROOT_FLAGS} -arch x86_64 -Xarch_x86_64
> \"-isysroot${SDK_IPHONE_SIMULATOR_ROOT}\"")
>
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${SYSROOT_FLAGS}" CACHE INTERNAL
> "CMake C Compiler Flags")
>
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${SYSROOT_FLAGS}" CACHE INTERNAL
> "CMake CXX Compiler Flags")
>
> else()
>
> SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -arch armv7 -arch armv7s -arch
> arm64")
>
> SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -arch armv7 -arch armv7s -arch
> arm64")
>
> endif()
>
>
>
> # CMAKE_CXX_FLAGS
>
> if(MAKE_FAT)
>
> set(CMAKE_OSX_SYSROOT "" CACHE INTERNAL "sysroot" FORCE)
>
> else()
>
> set(CMAKE_OSX_SYSROOT ${SDK_IPHONE_ROOT} CACHE INTERNAL "sysroot" FORCE)
>
> endif()
>
>
>
> add_library(${PROJECT_NAME} SHARED
>
> lib.h
>
> lib.cpp
>
> )
>
>
>
> # Framework properties
>
> set_target_properties(${PROJECT_NAME} PROPERTIES
>
> FRAMEWORK TRUE
>
> FORCE_IOS_BUNDLE_LAYOUT TRUE
>
> MACOSX_FRAMEWORK_IDENTIFIER ${PROJECT_NAME}
>
> MACOSX_FRAMEWORK_BUNDLE_VERSION 1.0
>
> MACOSX_FRAMEWORK_SHORT_VERSION_STRING 1.0
&g
Re: [cmake-developers] Preferred case for macro names?
On Tue, Nov 13, 2018 at 9:51 AM Joachim Wuttke wrote: > My understanding was that prevalent usage in modern CMake > is all lowercase for function names, all uppercase for > macro names. In this sense, I submitted a number of merge > requests where function and macro names are normalized, and > in >https://gitlab.kitware.com/cmake/cmake/merge_requests/2607 > I suggest an explicit recommendation in the macro and > function doc pages. > > Now I am learning from Craig Scott that the more recent > convention is actually all lowercase for macros as well > as for functions. > To be clear, my understanding is that in the past (many years ago), uppercase tended to be common, but I don't see that used much these days for functions, macros or built-in commands. The general sentiment seems to be that uppercase tends to be a bit "shouty" now. I'm suggesting that if we're going to bring some consistency to the docs, I propose that we just go with lowercase everywhere (functions, macros, built-in commands and examples). Regarding the finer points of macros versus functions versus built-in commands and establishing a convention, it's actually a bit difficult to draw a hard line in behaviour across all three. Consider commands like find_package() and project(). These are built-in commands, but they behave like a macros in that they add variables to the calling scope (yes, functions can do that too, but the primary reason to use macros is to inject variables into the calling scope). Most built-in commands act more like functions and do not modify the calling scope. Trying to decide whether built-in commands act like macros and which do not and making them upper or lowercase based on that is unlikely to be a distinction that most users would make, so a mix of upper and lowercase for built-in commands would be unexpected. A consequence of this is that having macros and functions with differing case conventions would seem to create a potential inconsistency with whatever convention is used for built-in commands. The only way to really have consistency here would seem to be just use the one case convention, for which lowercase seems to be the logical and increasingly prevalent choice. > > Thus two requests for comments: > > - Shall the reference manual give a clear recommendation > on preferred case, to stear the community away from the > inherited anarchy? > The docs can be consistent throughout, but matters of style are ultimately up to individual projects and their own coding conventions. Over time, making the CMake docs present a consistent style will likely encourage projects that don't have a convention of their own to adopt that style out of familiarity. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] My previous message
You are using sudo for your git operations and to make directories, then trying to run cmake inside those directories without sudo. CMake won't be able to write to directories created (and therefore owned) by root in most cases (unless you have a very permissive umask set). I'd recommend not using sudo to do the git clone or directory creation. Running cmake under sudo would not be recommended. On Sun, Nov 4, 2018 at 6:22 PM Osman Zakir wrote: > Did no one see my previous message here? About the CMake errors in the > Docker image. I really don't know how to fix this so some help would > really be appreciated. It really is mainly about CMake right now, not > Docker itself. Both the Dockerfile and the part of the build output with > errors from CMake are attached to this message. > > I don't know what I could try either, or else I really would've tried > something before sending a message here. > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] include a file from the toolchain file
On Fri, Nov 2, 2018 at 3:25 AM Federico Kircheis <
federico.kirch...@gmail.com> wrote:
> As described on https://github.com/Kitware/CMake/ I'm writing here to
> check if the current behavior of cmake is really a bug.
>
> I'm having following issues with toolchains files.
>
> Here is my use case:
> I have a `toolchain.gcc.cmake` and a `toolchain.clang.cmake` toolchain
> files.
> Those files define variables for the gcc and clang compiler, and some
> settings (location of libraries, version numbers and so on) are common
> to both, and I would like to have a common `toolchain.cmake` toolchain
> file for that.
>
> If I write (uncomment on of the includes)
>
> -
> # toolchain.gcc.cmake
>
> #include(common_settings.cmake)
> #include(./common_settings.cmake)
> #include(${CMAKE_CURRENT_SOURCE_DIR}/common_settings.cmake)
> #include(${CMAKE_SOURCE_DIR}/common_settings.cmake)
> #include(${CMAKE_HOME_DIRECTORY}/common_settings.cmake)
>
> set(CMAKE_C_COMPILER gcc)
>
>
> and execute (an empty CMakeLists.txt in the current directory is
> sufficient)
>
>
> rm -rf build; mkdir build && (cd build && cmake
> -DCMAKE_TOOLCHAIN_FILE=../toolchain.gcc.cmake ..);
>
>
> then cmake complains:
>
>include could not find load file:
>
>
>
> /home/user/Workspace/toolchain/build/CMakeFiles/CMakeTmp/common_settings.cmake
> Call Stack (most recent call first):
>
> /home/user/Workspace/toolchain/build/CMakeFiles/3.12.3/CMakeSystem.cmake:6
> (include)
>
> /home/user/Workspace/toolchain/build/CMakeFiles/CMakeTmp/CMakeLists.txt:2
> (project)
>
>
> CMake Error at /usr/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake:37
> (try_compile):
>Failed to configure test project build system.
> Call Stack (most recent call first):
>CMakeLists.txt:3 (project)
>
>
> As far as I've understood, cmake runs some internal test where, for
> example, `CMAKE_CURRENT_SOURCE_DIR` would not be the source directory of
> my code, and therefore
> `include(${CMAKE_CURRENT_SOURCE_DIR}/common_settings.cmake)` obviously
> fails.
> Same holds for other variables.
>
>
> The problem is that there is no way to set a path relative to the
> toolchain file, at least I was not able to find any.
>
> The only possible fix is setting an absolute path, but this is not
> really a solution since it makes the toolchain not portable.
>
> Is there anything else I could try?
> Is there already an open issue? I was not able to find any on
> https://gitlab.kitware.com/cmake/cmake/issues/.
>
You should be able to use CMAKE_CURRENT_LIST_DIR to specify a location
relative to the toolchain file itself.
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
[cmake-developers] PIE flags on various platforms
I'm currently reviewing a merge request <https://gitlab.kitware.com/cmake/cmake/merge_requests/2465> that addresses problems with creating PIE executables. Is anyone here sufficiently familiar with Fuchsia, FreeBSD or NetBSD to be able to check whether the right flags are being used there (look at the relevant Modules/Platform/*.cmake file)? If there are other platform-specific issues which may need to be considered for these, I'm interested in hearing about those too (for the BSDs in particular, there seems to have been quite a bit of activity in this area a couple of years ago). Regards -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] Signing individual binary and problem with PackageMaker CPack generator
On Tue, Oct 23, 2018 at 4:43 PM Eric Noulard wrote: > Le lun. 22 oct. 2018 à 23:05, Craig Scott a > écrit : > >> >>> Yes I agree that having build rpath is useful. >>> I am not aware of any mechanism that enable calling some tool during >>> CPack's install step. >>> Moreover I don't use MacOS at all so I don't have any experience with >>> PackageMaker. >>> >>> May be some Mac user may shed some more light on this. >>> >> >> You should be able to do this using install(SCRIPT) or install(CODE), >> invoking the code signing through execute_process() as part of that >> script/code. >> > > I wasn't sure of that. > > So just to be clear do we know for sure that install(SCRIPT) > install(CODE) will run after the CMake builtin-generated install scripts? > The builtin generated install script for target includes stripping, so for > signing to work as expect we should be sure of the execution order? > Or may be you suggest not to install(TARGET) for the concerned target and > write install(SCRIPT) replacement for those? > My understanding is that install() commands are generally processed in the order in which they appear in the directory scope. It is unspecified how the order between directory scopes behaves, although this merge request <https://gitlab.kitware.com/cmake/cmake/merge_requests/2434> (now merged to master) makes things much more predictable. I missed the earlier detail about when stripping occurred in relation to installing. From what I can see, I think the stripping happens right after the executable is copied/installed. Have a look at the generated cmake_install.cmake file for one of your builds and search for CMAKE_INSTALL_DO_STRIP to see how things get processed. If you add your own install(CODE) or install(SCRIPT) calls after you've done the install(TARGETS) calls, I would expect them to come after the stripping, but I haven't tested this. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Signing individual binary and problem with PackageMaker CPack generator
On Tue, Oct 23, 2018 at 12:32 AM Eric Noulard wrote: > > > Le lun. 22 oct. 2018 à 11:56, Anatoly Belyaev a > écrit : > >> We use "PackageMaker" generator on MacOS. But i don't think it is CPack >> specific tool does call strip command. The code for RPATH rewrite and >> strip cmd is located in cmake_install.cmake. As i understand CPack calls >> make install to tmp dir and then creates package. >> > Unrelated to your question, but PackageMaker is deprecated (by Apple). Recent macOS releases don't even have it. You may want to look into productbuild instead. > > Sorry I've just realized it was in the title of your message. > I wasn't aware that stripping was done during install. > > >> Having different RPATH for build tree is useful. May be there is a way to >> call sign tool in the install stage? But reading the doc to CMake install >> command, doesn't help me find solution for this. >> > > Yes I agree that having build rpath is useful. > I am not aware of any mechanism that enable calling some tool during > CPack's install step. > Moreover I don't use MacOS at all so I don't have any experience with > PackageMaker. > > May be some Mac user may shed some more light on this. > You should be able to do this using install(SCRIPT) or install(CODE), invoking the code signing through execute_process() as part of that script/code. Taking a step back though, I don't know what your package contains, but if you're creating an app bundle, then you don't need CPack at all. An app bundle is already self contained and you should be able to get it to build with install RPATH, at which point it should find everything it needs. An advantage of building with install RPATH is that you can also make use of the XCODE_ATTRIBUTE target property support to set up the code signing and have Xcode/xcodebuild drive the whole code signing process for you. It's likely to be easier that way and is more compatible with tools like Fastlane <https://fastlane.tools>, if you end up heading in that direction. But if you have embedded frameworks, then yeah, you probably end up having to do things manually yourself (CMake doesn't yet handle those well and has no direct support for it). -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] how to debug CPack creation
On Sun, Oct 21, 2018 at 3:41 AM Илья Шипицин wrote:
>
>
> сб, 20 окт. 2018 г. в 18:31, Eric Noulard :
>
>>
>>> And the content is:
>>> $ rpm -qpl softether-vpnserver-5.1.9660-1.x86_64.rpm
>>> /lib
>>> /lib/systemd
>>> /lib/systemd/system
>>> /lib/systemd/system/softether-vpnserver.service
>>> /usr/libexec
>>> /usr/libexec/softether
>>> /usr/libexec/softether/vpnserver
>>> /usr/libexec/softether/vpnserver/hamcore.se2
>>> /usr/libexec/softether/vpnserver/vpnserver
>>> /usr/local
>>> /usr/local/bin
>>> /usr/local/bin/vpnserver
>>>
>>> the content of the .deb is similar:
>>> $ dpkg-deb -c softether-vpnserver_5.1.9660_amd64.deb
>>> drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/
>>> drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/systemd/
>>> drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/systemd/system/
>>> -rw-r--r-- root/root 700 2018-10-20 14:45
>>> ./lib/systemd/system/softether-vpnserver.service
>>> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/
>>> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/libexec/
>>> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/libexec/softether/
>>> drwxr-xr-x root/root 0 2018-10-20 14:45
>>> ./usr/libexec/softether/vpnserver/
>>> -rw-r--r-- root/root 1770716 2018-10-20 14:45
>>> ./usr/libexec/softether/vpnserver/hamcore.se2
>>> -rwxr-xr-x root/root 2088960 2018-10-20 14:45
>>> ./usr/libexec/softether/vpnserver/vpnserver
>>> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/local/
>>> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/local/bin/
>>> -rwxr-xr-x root/root72 2018-10-20 14:45 ./usr/local/bin/vpnserver
>>>
>>> The main question is, what filesystem layout do you expect for those
>>> files?
>>>
>>>
>> Now I think I get it.
>> IN vpnserver CMakeLists.txt you do:
>>
>> install_systemd_service("vpnserver"
>> "${CMAKE_SOURCE_DIR}/systemd/softether-vpnserver.service"
>> "${CMAKE_INSTALL_FULL_LIBEXECDIR}/softether/vpnserver/vpnserver")
>>
>> So at this point (during CMake config step)
>> "${CMAKE_INSTALL_FULL_LIBEXECDIR}/softether/vpnserver/vpnserver"
>> is /usr/local/softether/vpnserver/vpnserver
>>
>> In your install_systemd_service CMake macro wrapper you do:
>>
>> macro(install_systemd_service component file_path binary_path)
>> get_filename_component(file_name ${file_path} NAME)
>> get_filename_component(binary_directory ${binary_path} DIRECTORY)
>>
>> file(READ ${file_path} FILE_CONTENT)
>> string(REPLACE "[DIRECTORY]" ${binary_directory} FILE_CONTENT
>> ${FILE_CONTENT})
>> string(REPLACE "[BINARY]" ${binary_path} FILE_CONTENT ${FILE_CONTENT})
>> file(WRITE ${CMAKE_SOURCE_DIR}/tmp/systemd/${file_name}
>> ${FILE_CONTENT})
>> ...
>>
>> So you generate a systemd service file which contains /usr/local prefix
>> because this is the one which
>> is know during "CMake configuration step".
>>
>> You cannot do that this way with .deb or .rpm because you don't know the
>> "actual" prefix that will be in the package
>> because it is controlby CPACK_PACKAGING_INSTALL_PREFIX "at CPack time",
>> i.e. when CPack runs.
>>
>> It's even worse because .deb or .rpm may be relocated see e.g.:
>>
>> https://www.cyberciti.biz/faq/howto-install-rpm-package-into-another-directory/
>>
>> When you want to install script that should know where things get
>> installed you have 3 options:
>>
>> 1) Assume the binary executable is installed in the path
>> thus call the executable as-is "vpnserver" without absolute path
>>
>> 2) Put a pre- or post- install script that will compute the appropriate
>> path
>>**during package installation** when you are sure what the real path
>> will be.
>>Have a look at CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA in
>> https://cmake.org/cmake/help/latest/cpack_gen/deb.html
>> or
>> https://cmake.org/cmake/help/latest/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE
>>
>> 3) Ensure that you generate package with
>>CMAKE_INSTALL_PREFIX == CPACK_PACKAGING_INSTALL_PREFIX
>>This is ok but will break if the installation of the package is
>> relocated.
>>
>
> this is good.
> is there a way to install shared libs to system location ? (in order to
Re: [CMake] Controlling order of includes with INTERFACE_INCLUDE_DIRECTORIES for an IMPORTED target
On Fri, Oct 12, 2018 at 6:42 PM David Jobet
wrote:
> Hello,
>
> we embed in our source a copy of an ICC build of LLVM, that we import :
>
> add_library(global_llvm_external STATIC IMPORTED)
> set_property(TARGET global_llvm_external APPEND PROPERTY
> INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/icc/include)
> set_property(TARGET global_llvm_external APPEND PROPERTY
> IMPORTED_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMCore.a)
> set_property(TARGET global_llvm_external APPEND PROPERTY
> INTERFACE_LINK_LIBRARIES
> ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMLTO.a ...)
>
> add_library(global_llvm INTERFACE)
> target_link_libraries(global_llvm INTERFACE global_llvm_external)
> add_library(global::llvm ALIAS global_llvm)
>
> It works fine, until someone decided to install a more recent version
> of LLVM in its development env. (which is not ABI compatible)
>
> Somehow, system includes path are looked into first
> g++ ... -I/apps/homefs1/USER/work/. -I. -isystem
> /spare/local/USER/conda_root/envs/gcc6cxx14/include -isystem
> /apps/homefs1/USER/work/.../libllvm/icc/include ...
>
> so, as with include_directories where it's possible to control the
> ordering with BEFORE or AFTER, is there a way to tell cmake that when
> linking against global::llvm we want the include directories needed by
> global::llvm to be prepended (instead of appended) ?
>
>
While not directly answering your question, what version of CMake are you
using? There was a change related to this area in the following merge
request that went in for the 3.12 release:
https://gitlab.kitware.com/cmake/cmake/merge_requests/1968
The part that got my attention is the following claim in the description:
An effect of the -isystem flag is to search the directory after
> those specified via -I flags.
Which seems at odds with your observations/comments, unless I'm
misunderstanding what you're saying.
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] LOCATION target property, generator expressions
dd this to >>> >> -Wl,-rpath=$ORIGIN/[relative part]. We want to do the same w/o >>> LOCATION >>> >> (i.e. resolving CMP0026) >>> >> >>> >> On Thu, Sep 27, 2018 at 7:29 AM Brad King >>> wrote: >>> >> >>> >>> On 09/26/2018 10:23 AM, Hendrik Greving wrote: >>> >>> > Is there any way before 3.13 to achieve what I need? Right now we >>> >>> > modify LINK_FLAGS based on something that is computed with values >>> >>> > from LOCATION. >>> >>> [snip] >>> >>> > our cmake setup is using LOCATION property for two targets to >>> compute >>> >>> > a relative path from these two, and adds this to LINK_FLAGS >>> >>> > (for rpath, but irrelevant in this context). >>> >>> >>> >>> To at least see if 3.13 will support your use case, you could >>> >>> try a nightly binary from here: >>> >>> >>> >>> https://cmake.org/files/dev/?C=M;O=D >>> >>> >>> >>> Use `$/..` to refer to a path relative >>> >>> to the target file location. >>> >>> >>> >>> I've never seen a need to adjust link flags based on the target >>> >>> location. CMake has several features for RPATH support. What >>> >>> are you really trying to do? >>> >>> >>> >>> -Brad >>> >>> >>> >> >>> >>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >> -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Call function from name and list, including empty elements?
Sorry for the delay, a few more replies to your latest questions embedded below. On Sun, Sep 30, 2018 at 6:06 PM Jan Wielemaker wrote: > > > I've come as far as understanding: > > > > - The generator creates cmake_install.cmake > > - make/ninja/... install calls cmake -P cmake_install.cmake > > - This calls file(INSTALL ) > > > > So, I thought I can > > > > - Add a file cmake_ln_install.cmake that > > - redefines file() > > - includes cmake_install.cmake > > > > > > You will likely find it more convenient to use install(CODE) > > <https://cmake.org/cmake/help/latest/command/install.html#code> or > > install(SCRIPT) > > <https://cmake.org/cmake/help/latest/command/install.html#script> to > > define commands to add to the install process rather than trying to work > > with cmake_install.cmake directly. Those two forms of the install() > > command are the recommended way to get your own code into the > > cmake_install.cmake file that CMake generates. At the moment, you would > > need to use execute_process() to invoke cmake -E create_symlink to > > create the actual link within that code or script (see further below for > > state of the file() command for this). > > Ok. I'm already using some install(CODE) for post-copy installation > steps. I find the interface rather clumsy as you typically need to call > external processes and need to get the quotes right :( Good news is that > cmake allows you to hide all this stuff behind a function. So, I guess > your proposal would be to define a function that abstracts away over > installing the Prolog (data) files and uses one of the above if some > option is selected and the usual install(FILES ...) otherwise? > I'm not really making a proposal, but if you can see a robust way to hide away the clumsiness in your particular situation, then go for it. > > > I have a follow-up "part 2" article to the above one I linked, but it is > > still in preparation. It discusses other problems with trying to forward > > arguments using ARGN or ARGV, but some of the observations you've made > > here and in the linked stackoverflow article may also be relevant. If I > > get time, I'll try to see if I can incorporate some of the observations > > and behaviors you've raised. > > Is it a plan to have something that reliably does forward arguments? > I needed that in some of my internal abstractions (between my own > functions) and I've seen quite a few questions on how to do that. > For example, > > call_function(name a1 a2 ... list) > > where list is a variable name rather than an expanded variable, i.e., > the last argument is always a variable _name_? > I'm not aware of any active work going on to more robustly support argument forwarding. > P.s.Examining the source a bit further, it seems that installing > a file that is in fact a symlink will create a symlink. Would > a simple way around be to create a secondary tree next to the > source tree that copies the directory structure and symlinks > all the files work? > Erm, maybe try it and see, I don't know off the top of my head. ;) > > P.s.Migrating from autoconf/make to cmake was a lot of work > (about 2 weeks for converting 45 Makefile.in and 37 > configure.ac files), but make the build specification > a lot easier to follow and much shorter. Especially > using the ninja backend, building is quite a bit > faster as well. > Just wait until you get a chance to add ccache into the mix too. :D -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Computation of CMAKE_OSX_SYSROOT
On Mon, Oct 1, 2018 at 10:53 PM James Turner via CMake wrote: > Hi, > > The docs here: > > https://cmake.org/cmake/help/v3.12/variable/CMAKE_OSX_SYSROOT.html > > state that CMAKE_OSX_SYSROOT is computed from CMAKE_OSX_DEPLOYMENT_TARGET > if not explicitly set. Can anyone comment on how this works, because in my > setup it seems to be failing. This showed up as -isysroot not being passed > to the compiler, which then causes weird compile failures building on High > Sierra with Xcode 10 and the 10.14 SDK. > > If explicitly set SDKROOT or CMAKE_OSX_SYSROOT to the 10.14 SDK, > everything compiles fine. (Without passing -isysroot, some header is > /usr/include are used, and apparently these don’t work for building the > 10.14 frameworks) > > Deployment target is set to: > > set(CMAKE_OSX_DEPLOYMENT_TARGET "10.7”) > > Note that I do this *after* calling project() because contrary to its > docs, I find that when I call it before project(), it has no effect. (eg, > passing -mmacosx-version-min=10.7 to the compiler). > > Full CMakeList.txt is here: > > > https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/CMakeLists.txt > > Any comments on what is going on, would be appreciated. > You need to set CMAKE_OSX_DEPLOYMENT_TARGET as a *cache* variable before calling the project() command. If you set it as a normal (i.e. non-cache) variable, the compiler detection logic triggered by the project() call creates a cache variable if one doesn't exist, which would discard the non-cache variable. It's a bit unfortunate, but that's what happens when you set a cache variable for the first time. The relevant code related to your observations is in Modules/Platform/Darwin-Initialize.cmake. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Call function from name and list, including empty elements?
On Sun, Sep 30, 2018 at 2:28 AM Jan Wielemaker wrote:
> Hi
>
> I'm converting a big project (SWI-Prolog) to cmake. Still a newbie wrt.
> cmake, but quite happy. There is one thing that I can't get done:
> install the system using symbolic links to the source tree. This is in
> this case really handy for developers.
>
This would be very unusual. An installed project should not generally
require that the sources it was built from remain around.
>
> I've come as far as understanding:
>
>- The generator creates cmake_install.cmake
>- make/ninja/... install calls cmake -P cmake_install.cmake
>- This calls file(INSTALL )
>
> So, I thought I can
>
>- Add a file cmake_ln_install.cmake that
> - redefines file()
> - includes cmake_install.cmake
>
You will likely find it more convenient to use install(CODE)
<https://cmake.org/cmake/help/latest/command/install.html#code> or
install(SCRIPT)
<https://cmake.org/cmake/help/latest/command/install.html#script> to define
commands to add to the install process rather than trying to work with
cmake_install.cmake directly. Those two forms of the install() command are
the recommended way to get your own code into the cmake_install.cmake file
that CMake generates. At the moment, you would need to use
execute_process() to invoke cmake -E create_symlink to create the actual
link within that code or script (see further below for state of the file()
command for this).
>
> To redefine file(), I tried this to see whether this works:
>
> function(file)
>message("Calling file(${ARGN})")
>_file(${ARGN})
> endfunction()
>
Overriding built-in functions is strongly discouraged. Apart from relying
on undocumented CMake behavior, the above has the potential to result in
infinite recursion. I recently wrote a blog article about this which
explains in more detail:
https://crascit.com/2018/09/14/do-not-redefine-cmake-commands/
>
> But ... some of the file() calls contain empty strings ("") in the
> argument vector. All the rest works fine.
>
> On stack overflow [1], the suggestion was to use "${ARGN}", which
> indeed keeps the empty lists and works fine if the receiver is a
> function iterating over its argument vector. After downloading
> the cmake source it turns out file() is builtin (C++) and complains
> to require at least 2 arguments. I tried passing the first two
> as file(${arg1} ${arg2} "${ARGN}"), which would (I think) work for
> a user function, but doesn't for a builtin.
>
> [1]
> https://stackoverflow.com/questions/52480737/pass-empty-strings-in-cmake
> So, my question is
>
>- Is there a way to redefine a builtin function that passes
> empty strings correctly to the original?
>- If not, should this be considered a bug ...
>
Builtin functions should not be redefined, so no, it is not considered a
bug. ;)
I have a follow-up "part 2" article to the above one I linked, but it is
still in preparation. It discusses other problems with trying to forward
arguments using ARGN or ARGV, but some of the observations you've made here
and in the linked stackoverflow article may also be relevant. If I get
time, I'll try to see if I can incorporate some of the observations and
behaviors you've raised.
> P.s.I'd also like to see the possibility to create symlinks
> in cmake, other than calling cmake -E ...
>
There is already a feature request with discussion for that here:
https://gitlab.kitware.com/cmake/cmake/issues/16926
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Automatically set policies for shipped modules
On Mon, Sep 17, 2018 at 9:07 PM Brad King wrote: > On 09/17/2018 04:01 AM, Rolf Eike Beer wrote: > > I suggest that every module included from the CMake installation is > > considered clean for whatever we do and automatically gets a policy > > scope push/pop right from the C++ level. > > That's fine with me for policies like CMP0057 that affect the > CMake language features. We can't do that for every policy > because some policies affect the way modules behave for the > calling project. > > When include() or find_package() establishes the policy scope > for the included module we can inject a few settings. > We may also need to be careful about CMP0011 (Included scripts do automatic cmake_policy PUSH and POP), since that has come up before with regard to why some modules needed explicit policy push-pop even though include() would normally do that for us automatically. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Documentation of version comparisons needs updating
On Sun, Sep 16, 2018 at 6:57 AM Alan W. Irwin wrote: > The current (3.12.2) "if" documentation says, e.g., > > if( VERSION_LESS_EQUAL ) > Component-wise integer version number comparison (version format is > major[.minor[.patch[.tweak]]]). > > But what happens if any component of the version string is not an > integer, e.g., > > cmake version 3.12.20180915-g6f04e > > for the latest git version used for the cmake dashboard. It > appears from the > > CMAKE_CACHE_PATCH_VERSION:INTERNAL=20180915 > > CMakeCache.txt entry that the string "20180915-g6f04e" is reliably > converted in that case to the integer 20180915, but does that reliable > conversion also occur for the "if" VERSION comparisons? And if so, > shouldn't the "if" documentation say something about truncation of > trailing non-integer parts of the version components? > > What has lead me to these two questions is I am trying to distinguish > between the above version and 3.12.2, and since the documentation did > not acknowledge what would be done when non-integer strings were appended > to any of the integer components of the version string, I am concerned > the component integers might be determined in an unreliable way for > trailing non-integer string cases. > > After checking the code to confirm the behavior, I've put up a merge request with clarification of the docs. You can find it here: https://gitlab.kitware.com/cmake/cmake/merge_requests/2393 -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] ExternalProject, continuous integration and caching builds
On Wed, Sep 5, 2018 at 9:56 PM, Antoine Pitrou wrote: > > Hello, > > On our project (Apache Arrow - https://arrow.apache.org/) we're using > CMake for the C++ source tree and have many external dependencies > fetched using ExternalProject. In turn building those dependencies can > make up a significant portion of build times on CI services, especially > AppVeyor. So I've been looking for a solution to cache those > third-party builds from one CI run to the other. > > Right now, what I'm trying to do is to set EP_BASE to a well-known base > directory and ask AppVeyor to cache and restore that directory in each > new build. The AppVeyor caching seems to work fine (the EP_BASE > directory is saved and restored). However, it seems that nevertheless > CMake will rebuild all those projects again, despite the cached build > results. > When AppVeyor restores the cached directories and files, does it also preserve their timestamps? If not, that might explain why it always rebuilds. > > This is with CMake 3.12.1 on Windows. > > Here is the log for an example build step, here the zstd library: > https://ci.appveyor.com/project/pitrou/arrow/build/1. > 0.700/job/i4tj6tifp4xq1mjn?fullLog=true#L803 > > As you can see, CMake notices the downloaded tarball is up-to-date and > doesn't download it again, but it still extracts it again (why?) and > builds the source code anew. Yet the entire EP_BASE directory (here > "C:/Users/appveyor/arrow-externals") is cached and restored by AppVeyor. > > Did someone manage to make this work, and/or is there another solution? > > -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Quiet option for cmake
On Thu, Aug 23, 2018 at 8:02 PM, Craig Scott wrote: > > > On Thu, Aug 23, 2018 at 4:40 AM, Brad King wrote: > >> On 08/21/2018 05:04 PM, Craig Scott wrote: >> > A user has recently been asking about reducing the output coming from a >> > FetchContent population when nothing needs to be done >> > Because this is implemented as a sub-build, you always see the following >> > >> > -- Configuring done >> > -- Generating done >> > -- Build files have been written to: ... >> >> Isn't that output coming from the invocation here: >> >> https://gitlab.kitware.com/cmake/cmake/blob/v3.12.1/Modules/ >> FetchContent.cmake#L776-781 >> >> rather than inside ExternalProject? >> > > Yes, that is where I'd like to be able to use the proposed --quiet or > --silent option. > > > >> >> Why is that output not always captured? >> > > If you capture it, then you don't get to see it until the command has > completed. It can take non-trivial time and in some cases may require user > input (e.g. to enter a password for a private SSH key). If you captured the > output and the download hung for some reason, there would be no output to > give any indication of where the download was up to. For cases where you > don't expect problems, you can use the QUIET option and the output is > indeed captured and only output at the end. This is the default because > otherwise the output is rather noisy with all the ExternalProject step > logging. But for cases where you need to investigate problems, you don't > want the output captured. > > Now that I've said all that, I guess FetchContent could check if the > output of a QUIET run was just the above-mentioned three lines and drop > them to leave no output in that case. Might be the simpler solution. > Furthermore, for the second execute_process() call a few lines after the > one referenced above (which does the build stage of the sub-build), we > could potentially make use of the logging verbosity improvements in MR > 2129 <https://gitlab.kitware.com/cmake/cmake/merge_requests/2129> if/when > it is done to further minimise the output of the "nothing to do" case. > > Sorry, got my wires crossed a bit there. The QUIET option already fully absorbs the output unless there's an error. I missed this in the original issue that prompted this request. Let me go back to that issue and see if there's really anything needed here after all. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Quiet option for cmake
On Thu, Aug 23, 2018 at 4:40 AM, Brad King wrote: > On 08/21/2018 05:04 PM, Craig Scott wrote: > > A user has recently been asking about reducing the output coming from a > > FetchContent population when nothing needs to be done > > Because this is implemented as a sub-build, you always see the following > > > > -- Configuring done > > -- Generating done > > -- Build files have been written to: ... > > Isn't that output coming from the invocation here: > > https://gitlab.kitware.com/cmake/cmake/blob/v3.12.1/ > Modules/FetchContent.cmake#L776-781 > > rather than inside ExternalProject? > Yes, that is where I'd like to be able to use the proposed --quiet or --silent option. > > Why is that output not always captured? > If you capture it, then you don't get to see it until the command has completed. It can take non-trivial time and in some cases may require user input (e.g. to enter a password for a private SSH key). If you captured the output and the download hung for some reason, there would be no output to give any indication of where the download was up to. For cases where you don't expect problems, you can use the QUIET option and the output is indeed captured and only output at the end. This is the default because otherwise the output is rather noisy with all the ExternalProject step logging. But for cases where you need to investigate problems, you don't want the output captured. Now that I've said all that, I guess FetchContent could check if the output of a QUIET run was just the above-mentioned three lines and drop them to leave no output in that case. Might be the simpler solution. Furthermore, for the second execute_process() call a few lines after the one referenced above (which does the build stage of the sub-build), we could potentially make use of the logging verbosity improvements in MR 2129 <https://gitlab.kitware.com/cmake/cmake/merge_requests/2129> if/when it is done to further minimise the output of the "nothing to do" case. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] [cmake-developers] libc++ usage in CMake with Clang?
On Wed, Aug 22, 2018 at 1:39 PM, Ian Henriksen < insertinterestingnameh...@gmail.com> wrote: > > > On Tue, Aug 21, 2018 at 6:40 PM Craig Scott > wrote: > >> >> On Wed, Aug 22, 2018 at 7:18 AM, Robert Dailey >> wrote: >> >>> On Tue, Aug 21, 2018 at 3:47 PM Craig Scott >>> wrote: >>> > Excuse the brevity, but it sounds like you might be looking for the >>> CXX_EXTENSIONS target property (sorry if I've misunderstood your problem, >>> let me know why it isn't appropriate if so). See the following article for >>> a more complete overview of this and related properties: >>> > >>> > https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/ >>> >>> Unfortunately that's not the same. Extensions manage C++ language >>> features and STL capabilities, but -stdlib is for selecting an STL >>> implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++ >>> to clang). >>> >> >> Sorry, yes I misunderstood your problem. After a little digging, it seems >> like you probably shouldn't be using the -stdlib option on Linux >> <https://stackoverflow.com/a/50407611/1938798> anyway. FWIW, for >> Android, the roadmap >> <https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md> >> is converging on a single STL implementation too. >> > > All that first link says is that -stdlib is a flag that is specific to > clang and that it shouldn't be used with gcc. You can use clang on Linux > with either libstdc++ or libc++. I often use libc++ on Linux by setting > CMAKE_CXX_FLAGS on the command line, though I'll admit that for me it's > usually just to check if problems that come up are OS dependent, compiler > dependent, or standard library dependent. You have to be careful since > libstdc++ and libc++ have incompatible ABIs, but it's a useful feature. > That said, I have no idea if specifying the standard library implementation > merits handling at the CMake level since only clang supports switching > anyway. > Good clarification, thanks. I was only thinking GCC on Linux and wasn't considering clang (which was a bit dumb on my part - blame the lack of coffee early in the morning ;) ). Getting back to Robert's original query, the only part of the CMake code base that I can see attempting to account for a -stdlib option is for detection of gcc include paths, and this is only for Eclipse and CodeBlocks generators (according to the comments in Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake). It doesn't seem to be related to providing any support for manipulating it in a project. The only other place -stdlib seems to be mentioned is in the setup of the macOS release build of CMake itself, which isn't relevant to the discussion here. If CMake were to offer direct support for -stdlib, it sounds like it would be a clang-specific feature, so a clang-specific target property and/or variable may be a way forward, analogous to the way it is done for Android. Alternatively, maybe it could be done with generator expressions, but it would be a bit verbose and harder to ensure the same -stdlib was used consistently throughout if many targets were involved. But maybe just a fairly simple check is good enough here, something like this (using directory properties instead of variables): if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND NOT ANDROID) add_compile_options(-stdlib=libc++) # Presumably need the above for linking too, maybe other options missing as well add_link_options(-stdlib=libc++) # New command on CMake master, not in 3.12 release endif() The linking comments above are in response to discussions in a recent issue <https://gitlab.kitware.com/cmake/cmake/issues/18275> also related to the -stdlib option. One down side of the above is no transitive dependency details, something that a target property could achieve. I'll pause here and see what others think. > > Just my two cents though. > > Best, > > Ian > > >> Regarding your earlier comment: >> >> I'll explain a bit why I'm asking. I noticed that for code bases that >>> work on Android plus other UNIX platforms, they unconditionally >>> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by >>> default, which uses gnu stl + gcc/clang. So you get compiler errors. >>> There's no way for me to "search" a platform to see if it is eligible >>> for the libc++ flag, I simply have to either disable it completely or >>> conditionally include it based on target platform and/or toolchain. >>> None of these really address the root cause. >> >> If you are trying to control which STL to use for Android builds, C
Re: [cmake-developers] [CMake] libc++ usage in CMake with Clang?
On Wed, Aug 22, 2018 at 1:39 PM, Ian Henriksen < insertinterestingnameh...@gmail.com> wrote: > > > On Tue, Aug 21, 2018 at 6:40 PM Craig Scott > wrote: > >> >> On Wed, Aug 22, 2018 at 7:18 AM, Robert Dailey >> wrote: >> >>> On Tue, Aug 21, 2018 at 3:47 PM Craig Scott >>> wrote: >>> > Excuse the brevity, but it sounds like you might be looking for the >>> CXX_EXTENSIONS target property (sorry if I've misunderstood your problem, >>> let me know why it isn't appropriate if so). See the following article for >>> a more complete overview of this and related properties: >>> > >>> > https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/ >>> >>> Unfortunately that's not the same. Extensions manage C++ language >>> features and STL capabilities, but -stdlib is for selecting an STL >>> implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++ >>> to clang). >>> >> >> Sorry, yes I misunderstood your problem. After a little digging, it seems >> like you probably shouldn't be using the -stdlib option on Linux >> <https://stackoverflow.com/a/50407611/1938798> anyway. FWIW, for >> Android, the roadmap >> <https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md> >> is converging on a single STL implementation too. >> > > All that first link says is that -stdlib is a flag that is specific to > clang and that it shouldn't be used with gcc. You can use clang on Linux > with either libstdc++ or libc++. I often use libc++ on Linux by setting > CMAKE_CXX_FLAGS on the command line, though I'll admit that for me it's > usually just to check if problems that come up are OS dependent, compiler > dependent, or standard library dependent. You have to be careful since > libstdc++ and libc++ have incompatible ABIs, but it's a useful feature. > That said, I have no idea if specifying the standard library implementation > merits handling at the CMake level since only clang supports switching > anyway. > Good clarification, thanks. I was only thinking GCC on Linux and wasn't considering clang (which was a bit dumb on my part - blame the lack of coffee early in the morning ;) ). Getting back to Robert's original query, the only part of the CMake code base that I can see attempting to account for a -stdlib option is for detection of gcc include paths, and this is only for Eclipse and CodeBlocks generators (according to the comments in Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake). It doesn't seem to be related to providing any support for manipulating it in a project. The only other place -stdlib seems to be mentioned is in the setup of the macOS release build of CMake itself, which isn't relevant to the discussion here. If CMake were to offer direct support for -stdlib, it sounds like it would be a clang-specific feature, so a clang-specific target property and/or variable may be a way forward, analogous to the way it is done for Android. Alternatively, maybe it could be done with generator expressions, but it would be a bit verbose and harder to ensure the same -stdlib was used consistently throughout if many targets were involved. But maybe just a fairly simple check is good enough here, something like this (using directory properties instead of variables): if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND NOT ANDROID) add_compile_options(-stdlib=libc++) # Presumably need the above for linking too, maybe other options missing as well add_link_options(-stdlib=libc++) # New command on CMake master, not in 3.12 release endif() The linking comments above are in response to discussions in a recent issue <https://gitlab.kitware.com/cmake/cmake/issues/18275> also related to the -stdlib option. One down side of the above is no transitive dependency details, something that a target property could achieve. I'll pause here and see what others think. > > Just my two cents though. > > Best, > > Ian > > >> Regarding your earlier comment: >> >> I'll explain a bit why I'm asking. I noticed that for code bases that >>> work on Android plus other UNIX platforms, they unconditionally >>> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by >>> default, which uses gnu stl + gcc/clang. So you get compiler errors. >>> There's no way for me to "search" a platform to see if it is eligible >>> for the libc++ flag, I simply have to either disable it completely or >>> conditionally include it based on target platform and/or toolchain. >>> None of these really address the root cause. >> >> If you are trying to control which STL to use for Android builds, C
Re: [CMake] [cmake-developers] libc++ usage in CMake with Clang?
On Wed, Aug 22, 2018 at 7:18 AM, Robert Dailey wrote: > On Tue, Aug 21, 2018 at 3:47 PM Craig Scott > wrote: > > Excuse the brevity, but it sounds like you might be looking for the > CXX_EXTENSIONS target property (sorry if I've misunderstood your problem, > let me know why it isn't appropriate if so). See the following article for > a more complete overview of this and related properties: > > > > https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/ > > Unfortunately that's not the same. Extensions manage C++ language > features and STL capabilities, but -stdlib is for selecting an STL > implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++ > to clang). > Sorry, yes I misunderstood your problem. After a little digging, it seems like you probably shouldn't be using the -stdlib option on Linux <https://stackoverflow.com/a/50407611/1938798> anyway. FWIW, for Android, the roadmap <https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md> is converging on a single STL implementation too. Regarding your earlier comment: I'll explain a bit why I'm asking. I noticed that for code bases that > work on Android plus other UNIX platforms, they unconditionally > specify `-stdlib=libc++`, however this doesn't work on Ubuntu by > default, which uses gnu stl + gcc/clang. So you get compiler errors. > There's no way for me to "search" a platform to see if it is eligible > for the libc++ flag, I simply have to either disable it completely or > conditionally include it based on target platform and/or toolchain. > None of these really address the root cause. If you are trying to control which STL to use for Android builds, CMake variables like CMAKE_ANDROID_STL_TYPE are probably the more appropriate way to do that rather than hard-coding compiler flags. This would also mean that non-Android builds won't be affected since they would simply ignore that variable (and target properties it may affect) and should then pick up the right STL implementation automatically.The Android-specific variable would ideally be set in a toolchain file rather than in the project itself. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] [CMake] libc++ usage in CMake with Clang?
On Wed, Aug 22, 2018 at 7:18 AM, Robert Dailey wrote: > On Tue, Aug 21, 2018 at 3:47 PM Craig Scott > wrote: > > Excuse the brevity, but it sounds like you might be looking for the > CXX_EXTENSIONS target property (sorry if I've misunderstood your problem, > let me know why it isn't appropriate if so). See the following article for > a more complete overview of this and related properties: > > > > https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/ > > Unfortunately that's not the same. Extensions manage C++ language > features and STL capabilities, but -stdlib is for selecting an STL > implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++ > to clang). > Sorry, yes I misunderstood your problem. After a little digging, it seems like you probably shouldn't be using the -stdlib option on Linux <https://stackoverflow.com/a/50407611/1938798> anyway. FWIW, for Android, the roadmap <https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md> is converging on a single STL implementation too. Regarding your earlier comment: I'll explain a bit why I'm asking. I noticed that for code bases that > work on Android plus other UNIX platforms, they unconditionally > specify `-stdlib=libc++`, however this doesn't work on Ubuntu by > default, which uses gnu stl + gcc/clang. So you get compiler errors. > There's no way for me to "search" a platform to see if it is eligible > for the libc++ flag, I simply have to either disable it completely or > conditionally include it based on target platform and/or toolchain. > None of these really address the root cause. If you are trying to control which STL to use for Android builds, CMake variables like CMAKE_ANDROID_STL_TYPE are probably the more appropriate way to do that rather than hard-coding compiler flags. This would also mean that non-Android builds won't be affected since they would simply ignore that variable (and target properties it may affect) and should then pick up the right STL implementation automatically.The Android-specific variable would ideally be set in a toolchain file rather than in the project itself. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] Quiet option for cmake
A user has recently been asking <https://gitlab.kitware.com/cmake/cmake/issues/18257> about reducing the output coming from a FetchContent population when nothing needs to be done (i.e. the content has already been populated). Because this is implemented as a sub-build, you always see the following extra lines in the main project's configure output (during the main configure, I'm not talking here about the same messages at the end of the main configure): -- Configuring done -- Generating done -- Build files have been written to: ... I'm wondering if it makes sense to add support for a --quiet or --silent option to cmake (and probably ccmake and cmake gui) which would skip these messages? It would be an option question whether ordinary status messages and messages which don't set any message mode should still be output for such an option (maybe they would for --quiet but not for --silent). While FetchContent is the motivation for this, perhaps other uses of CMake may also find it useful as well. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] [cmake-developers] libc++ usage in CMake with Clang?
On Tue, Aug 21, 2018 at 11:41 PM, Robert Dailey
wrote:
> I'll explain a bit why I'm asking. I noticed that for code bases that
> work on Android plus other UNIX platforms, they unconditionally
> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
> default, which uses gnu stl + gcc/clang. So you get compiler errors.
> There's no way for me to "search" a platform to see if it is eligible
> for the libc++ flag, I simply have to either disable it completely or
> conditionally include it based on target platform and/or toolchain.
> None of these really address the root cause.
>
> I'm not even really sure what a find module for this would do... but
> typically find modules don't provide compiler flags, so I'm not sure
> if that's the right tool for the job. Would love to hear from the
> developers on this, so I've cross posted to the dev mailing list in
> this reply.
>
Excuse the brevity, but it sounds like you might be looking for the
CXX_EXTENSIONS target property (sorry if I've misunderstood your problem,
let me know why it isn't appropriate if so). See the following article for
a more complete overview of this and related properties:
https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/
> On Mon, Aug 20, 2018 at 10:05 PM Thompson, KT wrote:
> >
> > I'm also interested in the answer to Robert's question. I've been using
> >
> > set( CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -stdlib=libc++")
> >
> > but it seems like there should be a more elegant approach.
> >
> > -tk
> >
> > -Original Message-
> > From: CMake On Behalf Of Robert Dailey
> > Sent: Monday, August 20, 2018 11:48 AM
> > To: CMake
> > Subject: [CMake] libc++ usage in CMake with Clang?
> >
> > Is the only way to use libc++ to muck with compile flags? Or is there a
> proper find module for this or something? Is there a more CMake-esque way
> of specifying the STL library to use with the toolchain?
> > --
> >
> > 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
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake-developers
>
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] [CMake] libc++ usage in CMake with Clang?
On Tue, Aug 21, 2018 at 11:41 PM, Robert Dailey
wrote:
> I'll explain a bit why I'm asking. I noticed that for code bases that
> work on Android plus other UNIX platforms, they unconditionally
> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
> default, which uses gnu stl + gcc/clang. So you get compiler errors.
> There's no way for me to "search" a platform to see if it is eligible
> for the libc++ flag, I simply have to either disable it completely or
> conditionally include it based on target platform and/or toolchain.
> None of these really address the root cause.
>
> I'm not even really sure what a find module for this would do... but
> typically find modules don't provide compiler flags, so I'm not sure
> if that's the right tool for the job. Would love to hear from the
> developers on this, so I've cross posted to the dev mailing list in
> this reply.
>
Excuse the brevity, but it sounds like you might be looking for the
CXX_EXTENSIONS target property (sorry if I've misunderstood your problem,
let me know why it isn't appropriate if so). See the following article for
a more complete overview of this and related properties:
https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/
> On Mon, Aug 20, 2018 at 10:05 PM Thompson, KT wrote:
> >
> > I'm also interested in the answer to Robert's question. I've been using
> >
> > set( CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -stdlib=libc++")
> >
> > but it seems like there should be a more elegant approach.
> >
> > -tk
> >
> > -Original Message-
> > From: CMake On Behalf Of Robert Dailey
> > Sent: Monday, August 20, 2018 11:48 AM
> > To: CMake
> > Subject: [CMake] libc++ usage in CMake with Clang?
> >
> > Is the only way to use libc++ to muck with compile flags? Or is there a
> proper find module for this or something? Is there a more CMake-esque way
> of specifying the STL library to use with the toolchain?
> > --
> >
> > 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
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake-developers
>
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] Project referring to CSharp project generates incorrectly?
Philip, thanks for the concise description of the problem. Would you be
willing to report this in CMake's gitlab as an issue so we can better track
it and refer to it in merge requests, etc.? You can report a new issue here:
https://gitlab.kitware.com/cmake/cmake/issues/new
Thanks
On Fri, Aug 17, 2018 at 1:59 AM, Tessier, Philip @ Engility via CMake <
cmake@cmake.org> wrote:
> All,
>
> Thank you in advance,
>
>
> I'm an experienced CMake user, in the C++ realm. I'm presently working
> outside that realm, porting a 200-project solution from Visual Studio
> (.vcxproj, .csproj) files to CMake. I'm very pleased that CMake has adopted
> CSharp! Thank you!
>
>
> I seem to have uncovered a bug where one CSharp project depends on another.
>
>
> The first CMakeLists.txt:
> cmake_minimum_required(VERSION 3.12)
> project(DockPanel CSharp)
> ...
> add_library(DockPanel MODULE ${SOURCES_files_Compile} ${SOURCES_files_
> EmbeddedResource})
> set_property(TARGET DockPanel APPEND PROPERTY VS_DOTNET_REFERENCES
> "System")
>
>
> The second CMakeLists.txt:
> cmake_minimum_required(VERSION 3.12)
> project(CSharpFramework CSharp)
> ...
> add_library(CSharpFramework MODULE ${SOURCES_files_Compile}
> ${SOURCES_files_EmbeddedResource})
> target_link_libraries(CSharpFramework PUBLIC $<$:DockPanel>
> )
> set_property(TARGET CSharpFramework APPEND PROPERTY VS_DOTNET_REFERENCES
> "System")
>
> (I haven't shown everything, as I'm extracting these from a huge system,
> but I can elaborate if necessary...)
>
> CMake configures and generates (to VS2015) without error. Things proceed
> as expected until it's time to link the second project.
> Then, I get:
> ..\DockPanel\Debug\DockPanel.dll : fatal error LNK1107: invalid or
> corrupt file: cannot read at 0x358
>
> A bit of investigative work shows that the generated
> CSharpFramework.vcxproj contains, as expected:
>
> {DCCB7EE9-726F-3D42-A673-D6CCB4EF6675}
> DockPanel
>
>
> But, it also contains:
>
> ..\DockPanel\Release\DockPanel.dll;
> ...
> ...
>
>
> The inclusion of DockPanel.dll in the AdditionalDependencies section is, I
> believe, causing Visual Studio to try to open it as a '.lib', and failing.
> I expected the generated .vcxproj to contain only the ProjectReference
> section for DockPanel, and not include it in AdditionalDependencies.
>
> Can you confirm that this is a bug?
>
> Thank you,
> Phil
>
>
> --
>
> 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
>
>
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] CDash build groups email preferences not remaining filled
This is the mailing list for CMake developers. Please send your query to the CDash mailing list, which you can find here: https://www.cdash.org/mailing-lists/ On Thu, Aug 16, 2018 at 5:52 AM, Vasquez, Justin wrote: > Hi, > > I'm using CDash 2.4.0 to test my builds nightly. If I go to my project and > navigate to Settings -> Groups -> Current BuildGroups, there are three tabs > for Nightly, Continuous, and Experimental builds. When I click any of the > email preferences (normal, summary, or no email) and save the changes, the > buttons do not remain filled in when I refresh the page. This does not > occur for the other button types which are check boxes nor for the text > entry boxes. I queried the mysql database and can confirm that the email > preferences are being set correctly. I would like the option to see what > the current value of the email settings is just as I can see whether or not > if "email committers" is checked off. Is there a way to edit the .php files > to allow the email preferences buttons to remain filled? > > Justin > -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] Enabling SSL support by default when building CMake from source
When building CMake from source with default options, you typically end up without SSL support, even if the necessary libraries (i.e. OpenSSL) are available. I've been bitten by that in my earlier days building CMake and I've seen others have a similar experience. Is there any reason why this is the default behavior, or is it just that the logic hasn't been added to try to enable it by default if available? -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] setting FIXTURES_* and RESOURCE_LOCK caused permission denied for dependent test?
On Fri, Aug 3, 2018 at 12:56 PM, Quang Ha wrote:
> Hi all,
>
> I am facing the issue of FIXTURES for setting up dependent test. Using
> RESOURCE_LOCK. Currently, it looks something like this:
>
> ===
> set_test_properties(run_simulation PROPERTIES FIXTURES_SETUP
> ${simulation_name})
> set_test_properties(compare_results PROPERTIES FIXTURES_REQUIRED
> ${simulation_name})
>
> [...]
>
> set_test_properties(run_simulation compare_results PROPERTIES
> RESOURCE_LOCK data_${simulation_name})
> ===
>
> If I include the line of RESOURCE_LOCK, the compare_results test will
> failed with permission denied. Removing it will make it run fine. I don't
> think I'm doing anything wrong though - why such behaviour is observed?
>
There doesn't seem to be anything wrong with your example code above, but
the problem might be in the other things that you have omitted. Does
anything else use the same resource lock name? If so, those are most likely
the cause. The code above on its own should not be able to lead to the
behavior you have described, since the use of RESOURCE_LOCK only has the
effect of preventing tests with the same named resource from running
concurrently. It doesn't touch any files directly, only your tests
themselves would be doing that. The other thing I would check is the
specific reason why the compare_results test is complaining with the
message "permission denied". Maybe add more debug logging to the test case
to check what you expect to exist (or not exist) at the start of the test.
You can also make ctest show more output by adding the -V option which will
show all the commands and test output.
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] issue with CPack: RPM package was not generated!
On Tue, Jul 31, 2018 at 9:56 PM, Miroslav Kubiczek < miroslav.kubic...@gmail.com> wrote: > Hi All, > > I'm running cmake 3.10.1 and have this issue: > > $ make package > [ 50%] Built target Rest > [100%] Built target UT_RestLibrary > Run CPack packaging tool... > CPack: Create package using RPM > CPack: Install projects > CPack: - Run preinstall target for: XXXCommonCppLibrary > CPack: - Install project: XXXCommonCppLibrary > CPack: Create package > CPackRPM: Will use USER specified spec file: /data/git/common-cpp-libs/ > build/XXX-common-cpp-libs.spec > CMake Error at > /usr/local/cmake-3.10.1-Linux-x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2703 > (message): > RPM package was not generated! > /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM > Call Stack (most recent call first): > > /usr/local/cmake-3.10.1-Linux-x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2774 > (cpack_rpm_generate_package) > > > CPack Error: Error while execution CPackRPM.cmake > CPack Error: Problem compressing the directory > CPack Error: Error when generating package: XXX-common-cpp-libs > make: *** [package] Error 1 > > The rpm file is generated by those strange errors printed, make exits with > an error code and jenkins build fails. > Does anyone know how to fix this? > > A few things to check: - Have you given any install() commands in your project? The message above seems to be suggesting nothing was installed. - Are you overriding the .spec file rather than using the one CMake/CPack creates for you? If so, can you indicate why and maybe check its contents. Less likely this is the main issue, but worth covering anyway. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 3.12 rc2 to rc3 Regression
On Wed, Jul 18, 2018 at 11:04 PM, Michael Jackson < mike.jack...@bluequartz.net> wrote: > Searching the mailing list archives for the RC3 announcement I scrolled to > the bottom and found: > > Brad King (2): > Revert "target_link_libraries: Allow use with targets in other > directories" > CMake 3.12.0-rc3 > > Just curious what caused the issue to revert the change? > The original problem report was on the dev mailing list: https://cmake.org/pipermail/cmake-developers/2018-June/030740.html The longer history of how the feature evolved and was then reverted can be found here: https://gitlab.kitware.com/cmake/cmake/issues/17943 -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Cannot import a project twice when cross compiling (as host-tool and for the target arch)
Not quite sure if it fits your use case, but we use a technique at work basically as described in the following: https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run Your case sounds more complicated, but maybe the above technique might help if you can organise things that way. On Wed, Jul 11, 2018 at 10:54 PM, Settenvini, Matteo < matteo.settenv...@here.com> wrote: > Dear all, > > I have the following problem which I don't know how to best solve. > Any help is appreciated. > > == Use Case == > > Consider the following use case: > > * We are cross-compiling. > * A certain project A depends on project B in two different ways: > - it uses an executable target from B to generate some files, e.g. a > compiler. > - one of its libraries links against a library of B. > > We would like to be able to do (not possible with CMake at the moment): > > > find_package(B REQUIRED) > # use B::lib normally. When crosscompiling, it will be the one compiled > for the target. > > find_package(B REQUIRED NO_CMAKE_FIND_ROOT_PATH) > # use B::exe knowing that it will always run from the host system. > > > This is for instance a use case we have for flatbuffers / protobuf. > > IMPORTED and ALIAS targets should not be global, or it should be > possible to override them. Or else, it should be possible to > dynamically specify a namespace when importing targets through > find_package(). > > I opened a bug at https://gitlab.kitware.com/cmake/cmake/issues/18169, > but it got closed as there are no plans to change the way CMake works. > > The issue contains also a test case, if you'd like to try it out. > > == Problem == > > The user cannot import a project twice to get the appropriate targets > when cross-compiling: once for the host architecture and once for the > target architecture. > > Right now, the user needs to manually use e.g. find_program() instead > of relying on installed locations, which can be annoying if the > binaries are installed outside the environment PATH. This can be > worked around, but we would like to use targets in place of > find_program() or find_library() calls. > > The problem is much more apparent in big superbuilds where you have > hundreds of projects brought together in one build and no control over > components outside your own. It is too hard to ensure a stable > configuration order (so that find_package() is always called for the > host version before the target version, or vice-versa). > > == Help needed == > > How would you solve the issue, so that different targets are available > for both the version built for the host and target architectures? > > Note that sometimes these external projects are not under our control, > and they come directly from upstream as git submodules. So we would > like to touch them as little as possible. > > Bests, > Matteo Settenvini > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com -- 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
