Re: [CMake] How to build fully correctly versioned shared object files with cmake
Am 6. August 2018 22:29:21 MESZ schrieb Alexander Neundorf : >On 2018 M08 6, Mon 21:54:33 CEST Hendrik Sattler wrote: >> Am 6. August 2018 20:27:23 MESZ schrieb Philip Van Hoof >: >> >Hello everyone, >> > >> >I noticed that it sometimes happens that I find a package for a >shared >> >object file(s) (or DLLs, on platforms like Windows) that have a >build >> >set up using cmake, that doesn't set everything that should be set. >> > >> >Usually as packagers of various popular open source softwares >correct >> >enthusiasts' attempts at understanding the sometimes bizarre >> >complexities of for example autotools, but (although it's all less >> >complicated) also cmake, it ends up somewhat right. Somewhat. I >noticed >> >that especially in corporate world, things tend to go spectacularly >> >wrong. Almost without exception. >> > >> >In particular am I concerned about ABI versioning of shared object >> >files so that they are easy to package and distribute by various >> >operating systems (like, among others, Linux distributions). But >also >> >API versioning of development files (compiler header files and pkg- >> >config) and installing to the right installation paths. >> > >> >I wanted to invite the community to scrutinize some equivalent >examples >> >that I made for autotools (with libtool), qmake, cmake and meson. >> > >> >https://github.com/pvanhoof/dir-examples/ >> > >> >In particular I wanted to invite the cmake community to take a look >at >> >this example: >> > >> >https://github.com/pvanhoof/dir-examples/tree/master/cmake-example >> > >> >The idea is that the examples are as correct as possible. That means >> >the examples should simple and educational. Easing (some amount) of >> >platform independence (ie. supporting Windows) and packaging. >> >> Is there ANY reason to use libtool library versioning? It might >surprise >> people but it really is not any kind of standard. >> >> Just change the SOVERSION when you make incompatible ABI changes and >a >> normal library VERSION. There's really not more to it, especially >nothing >> like the sick results that libtool produces, sometimes. > >I agree. >I would recommend >Major version = SO version, increase it if you break ABI compatibility >Minor version: increase it if you add ABI compatible features >Patch version: increase it for bug fix releases. Right. See http://semver.org A tool to check is e.g. the abi compliance checker. It may be worth to mention that project version and library version may differ but that it also might confuse people. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v3.12.0-381-g90df5f6
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 90df5f673029ae5a9ca1e88fec9ed3aa67ad36d1 (commit) from 6038f0730a8b043328ad80ed2fdea66604bc6509 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=90df5f673029ae5a9ca1e88fec9ed3aa67ad36d1 commit 90df5f673029ae5a9ca1e88fec9ed3aa67ad36d1 Author: Kitware Robot AuthorDate: Tue Aug 7 00:01:05 2018 -0400 Commit: Kitware Robot CommitDate: Tue Aug 7 00:01:05 2018 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 209769e..842ce28 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 12) -set(CMake_VERSION_PATCH 20180806) +set(CMake_VERSION_PATCH 20180807) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
Re: [CMake] Using Different Computers for cmake and ctest
Maybe you could improve the CTest system to allow execute remotely, by a shared file system to hold the all built binary files, and do a RPC-like test, and redirect the all output and terminate code from the target GPU machine, it should be able to work. On Wed, Jul 18, 2018 at 10:50 PM Brian S wrote: > I currently use cmake/ctest to build and test my software. The software is > C++/CUDA. During the build step I don't need a GPU but in the test step I > do. I would like to build the code with cmake on a cluster with many CPUs > and then run the tests using ctest on a target machine with a GPU. Is this > possible? > > I have thought about using nvidia-docker but that only works on one of my > target platforms. > -- > > 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
Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules
Stephen Kelly wrote: >> The build.sh script shows the commands required to build it (though I >> haven't checked the exact fmodule-file dependencies to check that they're >> all necessary, etc) - and with current Clang top-of-tree it does build >> and run the example dinnerparty program. > > Ok. I tried with my several-weeks-old checkout and it failed on the first > command with -modules-ts in it (for AbstractFruit.cppm - the simplest > one). > > I'll update my build and try again, but that will take some time. I have locally tried your modifications. Aside from the content of my previous email, I updated my clone (force push) to clean up the commits, and to modify your build.sh script to maintain the different libraries in the repo. https://github.com/steveire/ModulesExperiments/commits/master I am still interested in what the C++ code (and build.sh) look like in the case of one-module-per-library. It is obvious from looking at build.sh as it is that the buildsystem needs to be changed when adding a new import to a c++ file, as I have described. see the commit adding Grape separately and the changes required to the buildsystem which were not required in the non-modules world: https://github.com/steveire/ModulesExperiments/commit/428bea53fc6 I will see if I can get a recent GCC build for comparison and to determine whether the callback-to-the-buildsystem used in GCC makes a difference in that respect. I'm still interested in a response to my previous email in that respect. Thanks, Stephen. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] How to build fully correctly versioned shared object files with cmake
Alexander Neundorf wrote: > On Mon, 2018-08-06 at 21:54 +0200, Hendrik Sattler wrote: > > Is there ANY reason to use libtool library versioning? It might > > surprise people but it really is not any kind of standard. > > > > Just change the SOVERSION when you make incompatible ABI changes > > and a normal library VERSION. There's really not more to it, > > especially nothing like the sick results that libtool produces, > > sometimes. > I agree. > I would recommend > Major version = SO version, increase it if you break ABI > compatibility > Minor version: increase it if you add ABI compatible features > Patch version: increase it for bug fix releases. > > Alex Ok, I added this note to README.md, cmake, meson and qmake examples: # When you don't care about compatibility with libtool's -version-info, then you can take the following rules for VERSION in cmake, meson and qmake: # * SOVERSION = Major version # * Major version: increase it if you break ABI compatibility # * Minor version: increase it if you add ABI compatible features # * Patch version: increase it for bug fix releases. https://github.com/pvanhoof/dir-examples/commit/02a9a2d23ddf3627f87dd7a1af74b42603c4f890 (Because yes, you're right that libtool's -version-info is just pointlessly complicated and messy for people who don't need to care) Kind regards, Philip Van Hoof signature.asc Description: This is a digitally signed message part -- 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 build fully correctly versioned shared object files with cmake
On 2018 M08 6, Mon 21:54:33 CEST Hendrik Sattler wrote: > Am 6. August 2018 20:27:23 MESZ schrieb Philip Van Hoof : > >Hello everyone, > > > >I noticed that it sometimes happens that I find a package for a shared > >object file(s) (or DLLs, on platforms like Windows) that have a build > >set up using cmake, that doesn't set everything that should be set. > > > >Usually as packagers of various popular open source softwares correct > >enthusiasts' attempts at understanding the sometimes bizarre > >complexities of for example autotools, but (although it's all less > >complicated) also cmake, it ends up somewhat right. Somewhat. I noticed > >that especially in corporate world, things tend to go spectacularly > >wrong. Almost without exception. > > > >In particular am I concerned about ABI versioning of shared object > >files so that they are easy to package and distribute by various > >operating systems (like, among others, Linux distributions). But also > >API versioning of development files (compiler header files and pkg- > >config) and installing to the right installation paths. > > > >I wanted to invite the community to scrutinize some equivalent examples > >that I made for autotools (with libtool), qmake, cmake and meson. > > > >https://github.com/pvanhoof/dir-examples/ > > > >In particular I wanted to invite the cmake community to take a look at > >this example: > > > >https://github.com/pvanhoof/dir-examples/tree/master/cmake-example > > > >The idea is that the examples are as correct as possible. That means > >the examples should simple and educational. Easing (some amount) of > >platform independence (ie. supporting Windows) and packaging. > > Is there ANY reason to use libtool library versioning? It might surprise > people but it really is not any kind of standard. > > Just change the SOVERSION when you make incompatible ABI changes and a > normal library VERSION. There's really not more to it, especially nothing > like the sick results that libtool produces, sometimes. I agree. I would recommend Major version = SO version, increase it if you break ABI compatibility Minor version: increase it if you add ABI compatible features Patch version: increase it for bug fix releases. Alex -- 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 build fully correctly versioned shared object files with cmake
On Mon, 2018-08-06 at 21:54 +0200, Hendrik Sattler wrote:
Hello Hendrik,
> > https://github.com/pvanhoof/dir-examples/tree/master/cmake-example
> >
> > The idea is that the examples are as correct as possible. That
> > means the examples should simple and educational. Easing (some
> > amount) of platform independence (ie. supporting Windows) and
> > packaging.
>
> Is there ANY reason to use libtool library versioning? It might
> surprise people but it really is not any kind of standard.
Right, I got a similar remark from the meson people. And I guess people
who are used to qmake will probably also rightfully wonder about this.
The reason is that I wanted to create four examples with identical
method of doing versioning, and that I wanted to refer to the autotools
mythbusters and official libtool documentation for the time being.
For the time being until there is a sort of community consensus
(crossing multiple popular build environments), and that this gets
documented somewhat 'officially'. Right now, GNU kinda sets the de
facto standard and GNU (fortunately or unfortunately) utilizes libtool
and autotools (a lot). (Please don't read that as me saying that's a
good thing, as I'm not saying that).
I did however tried to make it easy to change the variable fabrication
at the root of the projects (the cmake-example/CMakeLists.txt).
For the cmake example you could take these (which admittedly are not
necessarily easy to understand, but, documented):
set(CMAKE_EXAMPLE_CURRENT_VERSION 3)
set(CMAKE_EXAMPLE_REVISION_VERSION 0)
set(CMAKE_EXAMPLE_AGE_VERSION 1)
math(EXPR CMAKE_EXAMPLE_SOVERSION "${CMAKE_EXAMPLE_CURRENT_VERSION} -
${CMAKE_EXAMPLE_AGE_VERSION}")
set(CMAKE_EXAMPLE_VERSION
${CMAKE_EXAMPLE_SOVERSION}.
${CMAKE_EXAMPLE_AGE_VERSION}.
${CMAKE_EXAMPLE_REVISION_VERSION})
And replace them with these (or something like these):
set(CMAKE_EXAMPLE_SOVERSION "2")
set(CMAKE_EXAMPLE_VERSION "2.1.0")
> Just change the SOVERSION when you make incompatible ABI changes and
> a normal library VERSION. There's really not more to it, especially
> nothing like the sick results that libtool produces, sometimes.
nod.
However. I'm not sure about trying to explain different versioning
style for equivalent examples (and in my examples I also include a
autotools one - unfortunately, or fortunately for people who are
converting from a autotools to a cmake, for example. Which is also
among the educational purposes of the examples).
I guess I could document it a little bit better in README.md ...
If people have suggestions? Just, however, let's try to keep it easy
for people coming from libtool-world. A lot of people do.
> The difficult thing is to realize the need for such a change. But
> there are tools that can help.
nod. I tried to explain the necessity in README.md.
I think it would be helpful to mention the tools, though. Suggestions
are welcome.
Thanks,
Kind regards,
Philip Van Hoof
signature.asc
Description: This is a digitally signed message part
--
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 Different Computers for cmake and ctest
Hi, CTest should work. You would just need to set the paths to the executable you want to test. In my case, I have my tests in a different repository than my source code. Regards, Juan On 8/6/18 3:00 PM, Alexander Neundorf wrote: On 2018 M07 18, Wed 09:49:47 CEST Brian S wrote: I currently use cmake/ctest to build and test my software. The software is C++/CUDA. During the build step I don't need a GPU but in the test step I do. I would like to build the code with cmake on a cluster with many CPUs and then run the tests using ctest on a target machine with a GPU. Is this possible? as far as I know this is currently not possible. I would also like to do that, to test the same executable on a set of different clusters (or at least with a different number of nodes. For that there is no need to rebuild the project multiple times. For tests, cmake generates CTestTestFile.cmake. These are executed when running a test. Copying the buildtree somewhere and then see what happens when you run ctest. E.g. RPATHs probably won't be correct. The tests may also have references into the source directory. Having a nice way to do this properly would be nice IMO :-) Alex -- 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] simple find_package example
On 2018 M08 2, Thu 10:01:39 CEST Randy Heiland wrote: > Hi, > > I'd like to figure out how to modify the simple "hello" demo ( > https://cmake.org/examples/) so that the Hello project is a library with an > accompanying FindHello.cmake and then the Demo project uses that > information and "find_package" to discover/use it. > > Hopefully that makes sense. Basically, I'm looking for a simple tutorial on > how I can make my library easily accessible to a CMake project. for that, you don't want a FindHello.cmake (which would typically be shipped either by cmake or by the consuming application), instead you want to generate and install a HelloConfig.cmake file. Alex -- 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 Different Computers for cmake and ctest
On 2018 M07 18, Wed 09:49:47 CEST Brian S wrote: > I currently use cmake/ctest to build and test my software. The software is > C++/CUDA. During the build step I don't need a GPU but in the test step I > do. I would like to build the code with cmake on a cluster with many CPUs > and then run the tests using ctest on a target machine with a GPU. Is this > possible? as far as I know this is currently not possible. I would also like to do that, to test the same executable on a set of different clusters (or at least with a different number of nodes. For that there is no need to rebuild the project multiple times. For tests, cmake generates CTestTestFile.cmake. These are executed when running a test. Copying the buildtree somewhere and then see what happens when you run ctest. E.g. RPATHs probably won't be correct. The tests may also have references into the source directory. Having a nice way to do this properly would be nice IMO :-) Alex -- 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 build fully correctly versioned shared object files with cmake
Am 6. August 2018 20:27:23 MESZ schrieb Philip Van Hoof : >Hello everyone, > >I noticed that it sometimes happens that I find a package for a shared >object file(s) (or DLLs, on platforms like Windows) that have a build >set up using cmake, that doesn't set everything that should be set. > >Usually as packagers of various popular open source softwares correct >enthusiasts' attempts at understanding the sometimes bizarre >complexities of for example autotools, but (although it's all less >complicated) also cmake, it ends up somewhat right. Somewhat. I noticed >that especially in corporate world, things tend to go spectacularly >wrong. Almost without exception. > >In particular am I concerned about ABI versioning of shared object >files so that they are easy to package and distribute by various >operating systems (like, among others, Linux distributions). But also >API versioning of development files (compiler header files and pkg- >config) and installing to the right installation paths. > >I wanted to invite the community to scrutinize some equivalent examples >that I made for autotools (with libtool), qmake, cmake and meson. > >https://github.com/pvanhoof/dir-examples/ > >In particular I wanted to invite the cmake community to take a look at >this example: > >https://github.com/pvanhoof/dir-examples/tree/master/cmake-example > >The idea is that the examples are as correct as possible. That means >the examples should simple and educational. Easing (some amount) of >platform independence (ie. supporting Windows) and packaging. Is there ANY reason to use libtool library versioning? It might surprise people but it really is not any kind of standard. Just change the SOVERSION when you make incompatible ABI changes and a normal library VERSION. There's really not more to it, especially nothing like the sick results that libtool produces, sometimes. The difficult thing is to realize the need for such a change. But there are tools that can help. >ps. I don't think CC-ing a huge amount of mailing lists is necessarily >a good idea. So feel free to forward to the appropriate people. > >ps. I attached no license to the examples yet. Perhaps I should attach >one? My goal would be that as much entities could copy and use it. >Including for, indeed, non-free purposes (as much as they want). > > >Kind regards, > >Philip Van Hoof -- 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] Install interface
Installing interface libraries has no effect without the 'EXPORT'
keyword as they have no artifacts, you will need to install the actual
archives to get any artifacts.
To generate a CMake file containing the correct import targets for
consumers of your project you should like at the 'EXPORT' keyword for
the install command (
https://cmake.org/cmake/help/latest/command/install.html#export )
On Sat, Aug 4, 2018 at 7:13 AM Quaquaraquà wrote:
>
> Good morning,
> given the following configuration:
>
> /CMakeLists.txt
> /include/
> /lib1/CMakeLists.txt
> /lib2/CMakeLists.txt
> ...
>
> where each /lib.*/CMakeLists.txt creates its own archive:
>
> add_library(lib.* EXCLUDE_FROM_ALL
> foo.cpp
> bar.cpp
> )
> target_link_libraries(lib1 PUBLIC interface)
>
> and the final /CMakeLists.txt should wrap all libraries together::
>
> add_library(interface INTERFACE)
> target_include_directories(interface INTERFACE include/)
> add_subdirectory(lib1 lib2 ...)
> add_library(libcommon INTERFACE)
> target_link_libraries(libcommon INTERFACE lib1 lib2 ...)
>
> I wonder how to create an install target for the final library `libcommon' ?
> This snippet doesn't seem effective with INTERFACE targets:
> install(TARGETS libcommon
> RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
> ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
> LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
> )
>
> Thanks,
> Quack
> --
>
> 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
Re: [CMake] cmake fails on first run but succeeds when run again after make
The error sounds like the file needs to be marked as GENERATED ( https://cmake.org/cmake/help/latest/prop_sf/GENERATED.html ) but I would have thought qt5_add_resources would do that for you. You might look at using CMake built in rc support ( https://cmake.org/cmake/help/latest/prop_tgt/AUTORCC.html )On Sun, Aug 5, 2018 at 4:54 AM Damir Porobic wrote: > > Hi folks, > > > I'm trying to troubleshoot a build problem where, when I first time run > "cmake .." it fails to find a resource file, when I run "make" it builds the > resource files but fails later on, now when I try to run "cmake .." again it > succeeds. After this point everything runs fine and it happens when building > for the first time. > > Any idea what I'm doing wrong? > > > Here are the CMakeList files https://pastebin.com/pyhVTJUr and the output > that I get https://pastebin.com/4wGjR3Lx > > > Thanks in advance! > > > Damir > > -- > > 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
[CMake] How to build fully correctly versioned shared object files with cmake
Hello everyone, I noticed that it sometimes happens that I find a package for a shared object file(s) (or DLLs, on platforms like Windows) that have a build set up using cmake, that doesn't set everything that should be set. Usually as packagers of various popular open source softwares correct enthusiasts' attempts at understanding the sometimes bizarre complexities of for example autotools, but (although it's all less complicated) also cmake, it ends up somewhat right. Somewhat. I noticed that especially in corporate world, things tend to go spectacularly wrong. Almost without exception. In particular am I concerned about ABI versioning of shared object files so that they are easy to package and distribute by various operating systems (like, among others, Linux distributions). But also API versioning of development files (compiler header files and pkg- config) and installing to the right installation paths. I wanted to invite the community to scrutinize some equivalent examples that I made for autotools (with libtool), qmake, cmake and meson. https://github.com/pvanhoof/dir-examples/ In particular I wanted to invite the cmake community to take a look at this example: https://github.com/pvanhoof/dir-examples/tree/master/cmake-example The idea is that the examples are as correct as possible. That means the examples should simple and educational. Easing (some amount) of platform independence (ie. supporting Windows) and packaging. ps. I don't think CC-ing a huge amount of mailing lists is necessarily a good idea. So feel free to forward to the appropriate people. ps. I attached no license to the examples yet. Perhaps I should attach one? My goal would be that as much entities could copy and use it. Including for, indeed, non-free purposes (as much as they want). Kind regards, Philip Van Hoof signature.asc Description: This is a digitally signed message part -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v3.12.0-380-g6038f07
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 6038f0730a8b043328ad80ed2fdea66604bc6509 (commit) via 670324bea29d484287ce0b81fe7cea52ba6e92bd (commit) from 1d76991a412873aa3a0aed9735a06d658ef367e7 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6038f0730a8b043328ad80ed2fdea66604bc6509 commit 6038f0730a8b043328ad80ed2fdea66604bc6509 Merge: 1d76991 670324b Author: Brad King AuthorDate: Mon Aug 6 12:52:39 2018 + Commit: Kitware Robot CommitDate: Mon Aug 6 08:52:45 2018 -0400 Merge topic 'update_maintainer_edit_label' 670324bea2 Help: Update maintainer edit checkbox label Acked-by: Kitware Robot Merge-request: !2263 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=670324bea29d484287ce0b81fe7cea52ba6e92bd commit 670324bea29d484287ce0b81fe7cea52ba6e92bd Author: Craig Scott AuthorDate: Mon Aug 6 21:44:00 2018 +1000 Commit: Craig Scott CommitDate: Mon Aug 6 22:50:39 2018 +1000 Help: Update maintainer edit checkbox label Recent GitLab updates have changed the label associated with the checkbox in merge request descriptions for allowing edits from maintainers. Make the contributor guidelines match the new label and add a note for why it is recommended. diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index 9e67703..84f6abb 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -36,7 +36,9 @@ To contribute patches: #. Push a topic branch to a personal repository fork on GitLab. #. Create a GitLab Merge Request targeting the upstream ``master`` branch (even if the change is intended for merge to the ``release`` branch). - Check the box to allow edits from maintainers. + Check the box labelled "Allow commits from members who can merge to the + target branch". This will allow maintainers to make minor edits on your + behalf. The merge request will enter the `CMake Review Process`_ for consideration. --- Summary of changes: CONTRIBUTING.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.12.0-378-g1d76991
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 1d76991a412873aa3a0aed9735a06d658ef367e7 (commit)
via 87e7904c915976456028fcd834bdea9bf07b47fd (commit)
from d7a1bcd2e67e27d8897c100f14744547ef639d64 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d76991a412873aa3a0aed9735a06d658ef367e7
commit 1d76991a412873aa3a0aed9735a06d658ef367e7
Merge: d7a1bcd 87e7904
Author: Brad King
AuthorDate: Mon Aug 6 12:43:46 2018 +
Commit: Kitware Robot
CommitDate: Mon Aug 6 08:43:54 2018 -0400
Merge topic 'autogen_single_entry'
87e7904c91 Autogen: Use a single AUTOGEN setup function in
cmGlobalGenerator
Acked-by: Kitware Robot
Merge-request: !2260
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=87e7904c915976456028fcd834bdea9bf07b47fd
commit 87e7904c915976456028fcd834bdea9bf07b47fd
Author: Sebastian Holtermann
AuthorDate: Fri Aug 3 12:55:50 2018 +0200
Commit: Sebastian Holtermann
CommitDate: Fri Aug 3 12:55:50 2018 +0200
Autogen: Use a single AUTOGEN setup function in cmGlobalGenerator
By moving all AUTOGEN setup code in ``cmGlobalGenerator``
into a single ``cmGlobalGenerator::QtAutoGen`` function, the
``cmGlobalGenerator::Compute`` function becomes cleaner.
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 63bbf04..58821c2 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1313,16 +1313,10 @@ bool cmGlobalGenerator::Compute()
// so create the map from project name to vector of local generators
this->FillProjectMap();
-#ifdef CMAKE_BUILD_WITH_CMAKE
- // Iterate through all targets and set up automoc for those which have
- // the AUTOMOC, AUTOUIC or AUTORCC property set
- auto autogenInits = this->CreateQtAutoGenInitializers();
- for (auto& autoGen : autogenInits) {
-if (!autoGen->InitCustomTargets()) {
- return false;
-}
+ // Iterate through all targets and set up AUTOMOC, AUTOUIC and AUTORCC
+ if (!this->QtAutoGen()) {
+return false;
}
-#endif
// Add generator specific helper commands
for (cmLocalGenerator* localGen : this->LocalGenerators) {
@@ -1341,16 +1335,6 @@ bool cmGlobalGenerator::Compute()
}
}
-#ifdef CMAKE_BUILD_WITH_CMAKE
- for (auto& autoGen : autogenInits) {
-if (!autoGen->SetupCustomTargets()) {
- return false;
-}
-autoGen.reset(nullptr);
- }
- autogenInits.clear();
-#endif
-
for (cmLocalGenerator* localGen : this->LocalGenerators) {
cmMakefile* mf = localGen->GetMakefile();
for (cmInstallGenerator* g : mf->GetInstallGenerators()) {
@@ -1480,12 +1464,11 @@ bool cmGlobalGenerator::ComputeTargetDepends()
return true;
}
-std::vector>
-cmGlobalGenerator::CreateQtAutoGenInitializers()
+bool cmGlobalGenerator::QtAutoGen()
{
+#ifdef CMAKE_BUILD_WITH_CMAKE
std::vector> autogenInits;
-#ifdef CMAKE_BUILD_WITH_CMAKE
for (cmLocalGenerator* localGen : this->LocalGenerators) {
const std::vector& targets =
localGen->GetGeneratorTargets();
@@ -1519,12 +1502,30 @@ cmGlobalGenerator::CreateQtAutoGenInitializers()
continue;
}
- autogenInits.emplace_back(new cmQtAutoGenInitializer(
+ autogenInits.emplace_back(cm::make_unique(
target, mocEnabled, uicEnabled, rccEnabled, qtVersionMajor));
}
}
+
+ if (!autogenInits.empty()) {
+// Initialize custom targets
+for (auto& autoGen : autogenInits) {
+ if (!autoGen->InitCustomTargets()) {
+return false;
+ }
+}
+
+// Setup custom targets
+for (auto& autoGen : autogenInits) {
+ if (!autoGen->SetupCustomTargets()) {
+return false;
+ }
+ autoGen.reset(nullptr);
+}
+ }
#endif
- return autogenInits;
+
+ return true;
}
cmLinkLineComputer* cmGlobalGenerator::CreateLinkLineComputer(
diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index a50cc3b..e0b97d2 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -33,7 +33,6 @@ class cmLinkLineComputer;
class cmLocalGenerator;
class cmMakefile;
class cmOutputConverter;
-class cmQtAutoGenInitializer;
class cmSourceFile;
class cmStateDirectory;
class cmake;
@@ -441,9 +440,9 @@ protected:
virtual bool CheckALLOW_DUPLICATE_CUSTOM_TARGETS() const;
- // Qt auto generators
- std::vector>
- CreateQtAutoGenInitializers();
+ /// @brief Qt AUTOMOC/UIC/RCC target generation
+ /// @return true on success
+ bool QtAutoGen();
std::string SelectMakeProgram(const std::string& makeProgram,
const
[Cmake-commits] CMake branch, master, updated. v3.12.0-376-gd7a1bcd
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via d7a1bcd2e67e27d8897c100f14744547ef639d64 (commit) via 6b7f1e1db0d84d9d83a34c7aee94967526ed2b0b (commit) via 39c91d07035d6fb8bddc6e02ee391a0f095e47ee (commit) from d64e41ac486847e74ff1c07bc2a80edbf63827fd (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d7a1bcd2e67e27d8897c100f14744547ef639d64 commit d7a1bcd2e67e27d8897c100f14744547ef639d64 Merge: d64e41a 6b7f1e1 Author: Brad King AuthorDate: Mon Aug 6 12:25:38 2018 + Commit: Kitware Robot CommitDate: Mon Aug 6 08:25:50 2018 -0400 Merge topic 'xcode_schemes_config' 6b7f1e1db0 Xcode: Add variables and properties to configure schemes 39c91d0703 cmGlobalGenerator: Add IsXcode query Acked-by: Kitware Robot Merge-request: !1803 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6b7f1e1db0d84d9d83a34c7aee94967526ed2b0b commit 6b7f1e1db0d84d9d83a34c7aee94967526ed2b0b Author: Gregor Jasny AuthorDate: Sun Jul 29 21:37:18 2018 +0200 Commit: Brad King CommitDate: Wed Aug 1 09:12:42 2018 -0400 Xcode: Add variables and properties to configure schemes Add `XCODE_SCHEME_*` target properties and associated variables `CMAKE_XCODE_SCHEME_*` to initialize them on target creation. Map each target property value to an associated Xcode scheme entry. Co-Author: Martin Sander Fixes: #17919 diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index 274206f..c9a38fc 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -339,6 +339,24 @@ Properties on Targets /prop_tgt/XCODE_ATTRIBUTE_an-attribute /prop_tgt/XCODE_EXPLICIT_FILE_TYPE /prop_tgt/XCODE_PRODUCT_TYPE + /prop_tgt/XCODE_SCHEME_ADDRESS_SANITIZER + /prop_tgt/XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN + /prop_tgt/XCODE_SCHEME_THREAD_SANITIZER + /prop_tgt/XCODE_SCHEME_THREAD_SANITIZER_STOP + /prop_tgt/XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER + /prop_tgt/XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP + /prop_tgt/XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER + /prop_tgt/XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP + /prop_tgt/XCODE_SCHEME_MALLOC_SCRIBBLE + /prop_tgt/XCODE_SCHEME_MALLOC_GUARD_EDGES + /prop_tgt/XCODE_SCHEME_GUARD_MALLOC + /prop_tgt/XCODE_SCHEME_ZOMBIE_OBJECTS + /prop_tgt/XCODE_SCHEME_MALLOC_STACK + /prop_tgt/XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE + /prop_tgt/XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS + /prop_tgt/XCODE_SCHEME_EXECUTABLE + /prop_tgt/XCODE_SCHEME_ARGUMENTS + /prop_tgt/XCODE_SCHEME_ENVIRONMENT /prop_tgt/XCTEST .. _`Test Properties`: diff --git a/Help/manual/cmake-variables.7.rst b/Help/manual/cmake-variables.7.rst index 48b1f20..5a3cd81 100644 --- a/Help/manual/cmake-variables.7.rst +++ b/Help/manual/cmake-variables.7.rst @@ -204,6 +204,21 @@ Variables that Change Behavior /variable/CMAKE_WARN_DEPRECATED /variable/CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION /variable/CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY + /variable/CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER + /variable/CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN + /variable/CMAKE_XCODE_SCHEME_THREAD_SANITIZER + /variable/CMAKE_XCODE_SCHEME_THREAD_SANITIZER_STOP + /variable/CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER + /variable/CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP + /variable/CMAKE_XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER + /variable/CMAKE_XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP + /variable/CMAKE_XCODE_SCHEME_MALLOC_SCRIBBLE + /variable/CMAKE_XCODE_SCHEME_MALLOC_GUARD_EDGES + /variable/CMAKE_XCODE_SCHEME_GUARD_MALLOC + /variable/CMAKE_XCODE_SCHEME_ZOMBIE_OBJECTS + /variable/CMAKE_XCODE_SCHEME_MALLOC_STACK + /variable/CMAKE_XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE + /variable/CMAKE_XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS /variable/PackageName_ROOT Variables that Describe the System diff --git a/Help/prop_tgt/XCODE_SCHEME_ADDRESS_SANITIZER.rst b/Help/prop_tgt/XCODE_SCHEME_ADDRESS_SANITIZER.rst new file mode 100644 index 000..694cd77 --- /dev/null +++ b/Help/prop_tgt/XCODE_SCHEME_ADDRESS_SANITIZER.rst @@ -0,0 +1,12 @@ +XCODE_SCHEME_ADDRESS_SANITIZER +-- + +Whether to enable ``Address Sanitizer`` in the Diagnostics +section of the generated Xcode scheme. + +This property is initialized by the value of the variable +:variable:`CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER` if it is set +when a target is created. + +Please refer to the :variable:`CMAKE_XCODE_GENERATE_SCHEME` variable
[Cmake-commits] CMake branch, release, updated. v3.12.0-21-gc776986
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via c7769867d6e195b5361c77ea54393c9cfaa12f94 (commit) via 37ba34c0b0270a09ca935d271f1742aea219070f (commit) from 3bab41f8f2971d3aa9fa40beb7263de8f340f1e9 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - --- Summary of changes: Modules/FindCUDA/select_compute_arch.cmake | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.12.0-373-gd64e41a
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via d64e41ac486847e74ff1c07bc2a80edbf63827fd (commit) via 7f981dcf0e6d0a1c01c49c0245218949fcfa75b6 (commit) via be095b3e7fcaf3773a994f546adafb383324e78b (commit) via bed7ee11b7b080e49fbdc107674140eecd4cd5b1 (commit) via 66be4621dabd86764bb007eabf605408626a7079 (commit) via 7142041abdebbdc677f7f859b03e12f68b8d0825 (commit) via 117d9f557042aa3a178e059cb038eaf0cb399b0a (commit) via 3a2c736b41fb394b389607b0ccf96611c42319f5 (commit) via c7769867d6e195b5361c77ea54393c9cfaa12f94 (commit) via 37ba34c0b0270a09ca935d271f1742aea219070f (commit) via 10d6c3a635fbcf84871dce3351156890ce566d1c (commit) via c2856e0b2b58c0c9cb4c089570009d517720812c (commit) via f34f6eb3d160d500c5c5e2cba131d64c75aa046a (commit) via 3434c22c290887a47bd70d6315aba8082a77110a (commit) from e19453d8ec91d7694ceb4729d68574ccd183476e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d64e41ac486847e74ff1c07bc2a80edbf63827fd commit d64e41ac486847e74ff1c07bc2a80edbf63827fd Merge: 7f981dc 10d6c3a Author: Brad King AuthorDate: Mon Aug 6 12:24:33 2018 + Commit: Kitware Robot CommitDate: Mon Aug 6 08:24:43 2018 -0400 Merge topic 'nag-fortran-rsp' 10d6c3a635 NAG: Pass response files through front-end to the linker Acked-by: Kitware Robot Merge-request: !2250 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f981dcf0e6d0a1c01c49c0245218949fcfa75b6 commit 7f981dcf0e6d0a1c01c49c0245218949fcfa75b6 Merge: be095b3 c2856e0 Author: Brad King AuthorDate: Mon Aug 6 12:23:37 2018 + Commit: Kitware Robot CommitDate: Mon Aug 6 08:24:04 2018 -0400 Merge topic 'xl-exe-pic' c2856e0b2b XL: Use -qpic for position independent executables Acked-by: Kitware Robot Merge-request: !2249 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=be095b3e7fcaf3773a994f546adafb383324e78b commit be095b3e7fcaf3773a994f546adafb383324e78b Merge: bed7ee1 f34f6eb Author: Brad King AuthorDate: Mon Aug 6 12:22:42 2018 + Commit: Kitware Robot CommitDate: Mon Aug 6 08:23:14 2018 -0400 Merge topic 'FindMatlab-mcc' f34f6eb3d1 FindMatlab: Add component to find MCC, the Matlab compiler Acked-by: Kitware Robot Merge-request: !2233 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bed7ee11b7b080e49fbdc107674140eecd4cd5b1 commit bed7ee11b7b080e49fbdc107674140eecd4cd5b1 Merge: 66be4621 3434c22 Author: Brad King AuthorDate: Mon Aug 6 12:22:19 2018 + Commit: Kitware Robot CommitDate: Mon Aug 6 08:22:28 2018 -0400 Merge topic 'FindMatlab-cross-compile' 3434c22c29 FindMatlab: only search registry on windows hosts Acked-by: Kitware Robot Merge-request: !2248 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66be4621dabd86764bb007eabf605408626a7079 commit 66be4621dabd86764bb007eabf605408626a7079 Merge: 7142041 c776986 Author: Brad King AuthorDate: Mon Aug 6 08:21:11 2018 -0400 Commit: Brad King CommitDate: Mon Aug 6 08:21:11 2018 -0400 Merge branch 'release-3.12' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7142041abdebbdc677f7f859b03e12f68b8d0825 commit 7142041abdebbdc677f7f859b03e12f68b8d0825 Merge: 117d9f5 37ba34c Author: Brad King AuthorDate: Mon Aug 6 12:20:49 2018 + Commit: Kitware Robot CommitDate: Mon Aug 6 08:20:54 2018 -0400 Merge topic 'cuda-arch-version' 37ba34c0b0 FindCUDA/select_compute_arch: Restore two-component CUDA_VERSION Acked-by: Kitware Robot Merge-request: !2251 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=117d9f557042aa3a178e059cb038eaf0cb399b0a commit 117d9f557042aa3a178e059cb038eaf0cb399b0a Merge: e19453d 3a2c736 Author: Brad King AuthorDate: Mon Aug 6 12:19:33 2018 + Commit: Kitware Robot CommitDate: Mon Aug 6 08:19:40 2018 -0400 Merge topic 'check-unique_ptr-pgi' 3a2c736b41 Extend C++17/C++14 feature checks to require unique_ptr Acked-by: Kitware Robot Merge-request: !2252 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3a2c736b41fb394b389607b0ccf96611c42319f5 commit 3a2c736b41fb394b389607b0ccf96611c42319f5 Author: Brad King AuthorDate: Wed Aug 1 14:01:47 2018 -0400 Commit: Brad King CommitDate: Wed Aug 1 14:03:43 2018 -0400 Extend C++17/C++14 feature checks to require unique_ptr When testing compiler modes higher than C++11 for constructs we need, include a check for using `unique_ptr` in that mode. The
[Cmake-commits] CMake branch, master, updated. v3.12.0-359-ge19453d
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via e19453d8ec91d7694ceb4729d68574ccd183476e (commit)
via bdd0174df1d611c709dd2865d0f07fdd2ac9fa27 (commit)
from d1d5709503b0917ca0700c386f629d00d92d538e (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e19453d8ec91d7694ceb4729d68574ccd183476e
commit e19453d8ec91d7694ceb4729d68574ccd183476e
Merge: d1d5709 bdd0174
Author: Brad King
AuthorDate: Mon Aug 6 11:55:16 2018 +
Commit: Kitware Robot
CommitDate: Mon Aug 6 07:55:24 2018 -0400
Merge topic 'file-WRITE-chmod'
bdd0174df1 file(WRITE): Avoid toggling permissions between 644 and 664
Acked-by: Kitware Robot
Merge-request: !2246
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bdd0174df1d611c709dd2865d0f07fdd2ac9fa27
commit bdd0174df1d611c709dd2865d0f07fdd2ac9fa27
Author: David Faure
AuthorDate: Wed Aug 1 11:32:30 2018 +0200
Commit: Brad King
CommitDate: Wed Aug 1 09:05:33 2018 -0400
file(WRITE): Avoid toggling permissions between 644 and 664
On systems with umask 022, this function would set permissions
to 664 and restore them to 644 at the end, every single time it was
called (which is many times on e.g. install_manifest.txt).
The intent of the code was to make non-writable files temporarily
writable and to restore permissions in the end, but really, if it's
already user-writable there's no point in toggling this back and forth.
diff --git a/Source/cmFileCommand.cxx b/Source/cmFileCommand.cxx
index 4c288f5..402ceb2 100644
--- a/Source/cmFileCommand.cxx
+++ b/Source/cmFileCommand.cxx
@@ -208,16 +208,20 @@ bool
cmFileCommand::HandleWriteCommand(std::vector const& args,
cmSystemTools::MakeDirectory(dir);
mode_t mode = 0;
+ bool writable = false;
// Set permissions to writable
if (cmSystemTools::GetPermissions(fileName.c_str(), mode)) {
-cmSystemTools::SetPermissions(fileName.c_str(),
#if defined(_MSC_VER) || defined(__MINGW32__)
- mode | S_IWRITE
+writable = mode & S_IWRITE;
+mode_t newMode = mode | S_IWRITE;
#else
- mode | S_IWUSR | S_IWGRP
+writable = mode & S_IWUSR;
+mode_t newMode = mode | S_IWUSR | S_IWGRP;
#endif
-);
+if (!writable) {
+ cmSystemTools::SetPermissions(fileName.c_str(), newMode);
+}
}
// If GetPermissions fails, pretend like it is ok. File open will fail if
// the file is not writable
@@ -242,7 +246,7 @@ bool
cmFileCommand::HandleWriteCommand(std::vector const& args,
return false;
}
file.close();
- if (mode) {
+ if (mode && !writable) {
cmSystemTools::SetPermissions(fileName.c_str(), mode);
}
return true;
diff --git a/Source/cmWriteFileCommand.cxx b/Source/cmWriteFileCommand.cxx
index d3d2db0..c504ef4 100644
--- a/Source/cmWriteFileCommand.cxx
+++ b/Source/cmWriteFileCommand.cxx
@@ -45,16 +45,20 @@ bool
cmWriteFileCommand::InitialPass(std::vector const& args,
cmSystemTools::MakeDirectory(dir);
mode_t mode = 0;
+ bool writable = false;
// Set permissions to writable
if (cmSystemTools::GetPermissions(fileName.c_str(), mode)) {
-cmSystemTools::SetPermissions(fileName.c_str(),
#if defined(_MSC_VER) || defined(__MINGW32__)
- mode | S_IWRITE
+writable = mode & S_IWRITE;
+mode_t newMode = mode | S_IWRITE;
#else
- mode | S_IWUSR | S_IWGRP
+writable = mode & S_IWUSR;
+mode_t newMode = mode | S_IWUSR | S_IWGRP;
#endif
-);
+if (!writable) {
+ cmSystemTools::SetPermissions(fileName.c_str(), newMode);
+}
}
// If GetPermissions fails, pretend like it is ok. File open will fail if
// the file is not writable
@@ -69,7 +73,7 @@ bool cmWriteFileCommand::InitialPass(std::vector
const& args,
}
file << message << std::endl;
file.close();
- if (mode) {
+ if (mode && !writable) {
cmSystemTools::SetPermissions(fileName.c_str(), mode);
}
---
Summary of changes:
Source/cmFileCommand.cxx | 14 +-
Source/cmWriteFileCommand.cxx | 14 +-
2 files changed, 18 insertions(+), 10 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits
Re: [cmake-developers] Compile flags depending on source file property
On 08/03/2018 07:12 PM, Simon Richter wrote:
> string(APPEND CMAKE_CXX_FLAGS
> "$,${WARN_SHADOW_OFF},${WARN_SHADOW_ON}> ")
The generators put the project-/target-wide flags in a place that
does not depend on the source being compiled so there would be no
way to evaluate that. On some generators per-source flags produce
a huge slowdown in the build (e.g. VS) so splitting up the settings
for every source is not practical.
We already run into this in the COMPILE_LANGUAGE generator expression:
https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html
See the note there about how it is handled on VS and Xcode.
> The only way I can think of doing this would be to remove the global
> warning flag definitions from the toplevel CMakeLists.txt
Per-source flags are placed after the target-wide flags on the command
line so you could just keep -Wshadow by default and then add -Wno-shadow
to the COMPILE_FLAGS source file property of the generated sources.
Alternatively you could use an object library for all the generated
sources and then set its target-wide flags to use "-Wno-shadow", or
even "-w".
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
