From tobias.hunger at gmail.com Thu Dec 1 01:44:53 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 1 Dec 2016 07:44:53 +0100 Subject: [cmake-developers] How to use cmake::SetCacheArgs(...)? In-Reply-To: <39d975f0-2475-bd8c-d476-1e3b3087d58b@kitware.com> References: <39d975f0-2475-bd8c-d476-1e3b3087d58b@kitware.com> Message-ID: Am 30.11.2016 19:10 schrieb "Brad King" : > If you want to ensure a fresh one-step configuration then always remove > CMakeCache.txt and CMakeFiles/ before configuring. People are really attached to their configuration and get upset when creator runs CMake. Creator running CMake with arguments is even more hated. Cleaning all settings and starting over with a clean configuration is the epitome of evil:-) Considering that there is no good way to figure out which settings were done by the user and what is auto-detected, it is basically impossible to restore the configuration from within Qt Creator:-( Users do set configuration options from within Qt Creator *and* from the command line, so I would need help from CMake to figure out the complete set of settings done by the user. Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Dec 1 08:08:50 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 1 Dec 2016 08:08:50 -0500 Subject: [cmake-developers] How to use cmake::SetCacheArgs(...)? In-Reply-To: References: <39d975f0-2475-bd8c-d476-1e3b3087d58b@kitware.com> Message-ID: On 12/01/2016 01:44 AM, Tobias Hunger wrote: > People are really attached to their configuration and get upset > when creator runs CMake. Creator running CMake with arguments > is even more hated. In that case why is creator passing or changing the compiler setting when it runs CMake? That should be fixed once the first time and never passed again. If you don't try to set/change the compiler then CMake won't wipe out the cache. -Brad From arankin at robarts.ca Thu Dec 1 12:02:40 2016 From: arankin at robarts.ca (Adam Rankin) Date: Thu, 1 Dec 2016 17:02:40 +0000 Subject: [cmake-developers] CMAKE_CXX_STANDARD seems to be ineffective (Ubuntu 14.04) Message-ID: <64c03acffdbc42c4b101a2cd1405f807@dag2.robarts.ca> Hello all, I have switched my project over to using the CMAKE_CXX_STANDARD variable and it does not seem to be recognized by the ITK external project that I configure/build. The project does not build (ITK tag 4.10.0) with CMAKE_CXX_STANDARD:STRING=11, but does build with CMAKE_CXX_FLAGS:STRING="... -std=c++11" Before I dive into too many details, is anyone familiar with any issues surrounding this variable? Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From arankin at robarts.ca Thu Dec 1 11:55:49 2016 From: arankin at robarts.ca (Adam Rankin) Date: Thu, 1 Dec 2016 16:55:49 +0000 Subject: [cmake-developers] CMAKE_CXX_STANDARD seems to be ineffective Message-ID: <5f69372198224c39afa24032da1243d3@dag2.robarts.ca> Hello all, I have switched my project over to using the CMAKE_CXX_STANDARD variable and it does not seem to be recognized by the ITK external project that I configure/build. Before I dive into too many details, is anyone familiar with any issues surrounding this variable? I currently have it set as a string variable with the value 11. Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Dec 1 13:29:46 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 1 Dec 2016 13:29:46 -0500 Subject: [cmake-developers] CMAKE_CXX_STANDARD seems to be ineffective (Ubuntu 14.04) In-Reply-To: <64c03acffdbc42c4b101a2cd1405f807@dag2.robarts.ca> References: <64c03acffdbc42c4b101a2cd1405f807@dag2.robarts.ca> Message-ID: On 12/01/2016 12:02 PM, Adam Rankin wrote: > Before I dive into too many details, is anyone familiar with any issues > surrounding this variable? It is well-tested and known to work in general. There are still some problems like not propagating into try_compile. It is also not sent automatically through ExternalProject_Add, but that is intentional. You'll have to dig in to your particular case. -Brad From chuck.atkins at kitware.com Fri Dec 2 10:16:00 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 2 Dec 2016 10:16:00 -0500 Subject: [cmake-developers] CMAKE_CXX_STANDARD seems to be ineffective (Ubuntu 14.04) In-Reply-To: <64c03acffdbc42c4b101a2cd1405f807@dag2.robarts.ca> References: <64c03acffdbc42c4b101a2cd1405f807@dag2.robarts.ca> Message-ID: Make sure you also set CMAKE_CXX_STANDARD_REQUIRED to TRUE, otherwise if the requested standard can't be found with the current compiler then you'll get a fallback to one that can. With the required set to TRUE, CMake will error out with something about the current compiler not supporting the requested standard. ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183 On Thu, Dec 1, 2016 at 12:02 PM, Adam Rankin wrote: > Hello all, > > > > I have switched my project over to using the CMAKE_CXX_STANDARD variable > and it does not seem to be recognized by the ITK external project that I > configure/build. > > > > The project does not build (ITK tag 4.10.0) with > CMAKE_CXX_STANDARD:STRING=11, but does build with CMAKE_CXX_FLAGS:STRING=?? > -std=c++11? > > > > Before I dive into too many details, is anyone familiar with any issues > surrounding this variable? > > > > Cheers, > > Adam > > > > -- > > 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: > http://public.kitware.com/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Wed Dec 7 10:02:56 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 7 Dec 2016 10:02:56 -0500 Subject: [cmake-developers] Building CMake system libraries Message-ID: What's the use case for the various ways to use a system version of a dependency in CMake's build? There seems to be CMAKE_USE_SYSTEM_LIBRARIES for initializing all of them and then CMAKE_USE_SYSTEM_LIBRARY_FOO to override that but then also the user-facing option CMAKE_USE_SYSTEM_FOO which is force-set to CMAKE_USE_SYSTEM_LIBRARY_FOO. I'm trying to understand why there's both CMAKE_USE_SYSTEM_LIBRARY_FOO and CMAKE_USE_SYSTEM_FOO when it seems that the user-facing option CMAKE_USE_SYSTEM_FOO isn't usually settable. Wouldn't it feasible to just have the user-facing CMAKE_USE_SYSTEM_FOO and not deal with the seperate CMAKE_USE_SYSTEM_LIBRARY_FOO? ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Dec 7 10:33:08 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 7 Dec 2016 10:33:08 -0500 Subject: [cmake-developers] Building CMake system libraries In-Reply-To: References: Message-ID: <90253ac2-622f-b95f-4a27-e8141e802f47@kitware.com> On 12/07/2016 10:02 AM, Chuck Atkins wrote: > I'm trying to understand why there's both CMAKE_USE_SYSTEM_LIBRARY_FOO > and CMAKE_USE_SYSTEM_FOO when it seems that the user-facing option > CMAKE_USE_SYSTEM_FOO isn't usually settable. This is for interaction with the bootstrap script. Options to that come in as cache entries that set the default for the user-facing options IIRC. -Brad From chuck.atkins at kitware.com Wed Dec 7 11:00:58 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 7 Dec 2016 11:00:58 -0500 Subject: [cmake-developers] Building CMake system libraries In-Reply-To: <90253ac2-622f-b95f-4a27-e8141e802f47@kitware.com> References: <90253ac2-622f-b95f-4a27-e8141e802f47@kitware.com> Message-ID: Shouldn't we be able to accomplish the same same thing with just the CMAKE_USE_SYSTEM_FOO variable as a cache entry? I ran into this when trying to build CMake master and I want to use all system libraries but librhash. Given the current implementation, there's a number of configurations that cause no way to actually set this with the user-facing option. Typically I'd do -DCMAKE_USE_SYSTEM_LIBRARIES=ON -DCMAKE_USE_SYSTEM_LIBRHASH=OFF but the user-facing option has no meaning because internally the CMAKE_USE_SYSTEM_LIBRARY_RHASH variable, initialized by CMAKE_USE_SYSTEM_LIBRARIES force overrides anything I try to set for it. ---------- Chuck Atkins On Wed, Dec 7, 2016 at 10:33 AM, Brad King wrote: > On 12/07/2016 10:02 AM, Chuck Atkins wrote: > > I'm trying to understand why there's both CMAKE_USE_SYSTEM_LIBRARY_FOO > > and CMAKE_USE_SYSTEM_FOO when it seems that the user-facing option > > CMAKE_USE_SYSTEM_FOO isn't usually settable. > > This is for interaction with the bootstrap script. Options to that > come in as cache entries that set the default for the user-facing > options IIRC. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Dec 7 11:07:11 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 7 Dec 2016 11:07:11 -0500 Subject: [cmake-developers] Building CMake system libraries In-Reply-To: References: <90253ac2-622f-b95f-4a27-e8141e802f47@kitware.com> Message-ID: On 12/07/2016 11:00 AM, Chuck Atkins wrote: > Shouldn't we be able to accomplish the same same thing with > just the CMAKE_USE_SYSTEM_FOO variable as a cache entry? If you can refactor the logic for that then go for it. Note the `if(CMAKE_BOOTSTRAP)` blocks. IIRC they make the bootstrap script options apply only when configured via that script, but then fall back to whatever the user changes after that. -Brad From craig.scott at crascit.com Thu Dec 8 01:41:28 2016 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 8 Dec 2016 17:41:28 +1100 Subject: [cmake-developers] Specifying sources without file extensions Message-ID: I've come across some projects where the source files listed in their add_executable() and add_library() commands do not have file extensions. It seems that CMake still finds the sources by trying some set of file suffixes. This is not documented behaviour, but it does show up in error messages if you give those commands a file name for a non-existent source. For example, if I specify a full filename which doesn't exist, I see an error message similar to the following: CMake Error at /somepath/CMakeLists.txt:10 (add_library): Cannot find source file: ../somethingThatDoesNotExist.h Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx So my question is whether specifying source file names without extensions is a feature which is simply missing documentation or is it an undocumented feature that projects are not supposed to use? Since there are error messages like the above, it would seem that the latter would be a harder position to justify. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Dec 8 08:01:03 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 8 Dec 2016 08:01:03 -0500 Subject: [cmake-developers] Specifying sources without file extensions In-Reply-To: References: Message-ID: <0be69164-95a1-d460-b3eb-87bed265a0bc@kitware.com> On 12/08/2016 01:41 AM, Craig Scott wrote: > file names without extensions is a feature which is simply missing > documentation or is it an undocumented feature that projects are not > supposed to use? Since there are error messages like the above, it > would seem that the latter would be a harder position to justify. It is an ancient legacy behavior from CMake's earliest days when it was only used for C++ projects with lists of "classes" where each was expected to have a source and header file. The behavior should be removed with a new policy, but no one has actually done that yet. -Brad From ben.boeckel at kitware.com Thu Dec 8 08:15:58 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 8 Dec 2016 08:15:58 -0500 Subject: [cmake-developers] Specifying sources without file extensions In-Reply-To: <0be69164-95a1-d460-b3eb-87bed265a0bc@kitware.com> References: <0be69164-95a1-d460-b3eb-87bed265a0bc@kitware.com> Message-ID: <20161208131558.GA22568@megas.kitware.com> On Thu, Dec 08, 2016 at 08:01:03 -0500, Brad King wrote: > On 12/08/2016 01:41 AM, Craig Scott wrote: > > file names without extensions is a feature which is simply missing > > documentation or is it an undocumented feature that projects are not > > supposed to use? Since there are error messages like the above, it > > would seem that the latter would be a harder position to justify. > > It is an ancient legacy behavior from CMake's earliest days when it > was only used for C++ projects with lists of "classes" where each > was expected to have a source and header file. The behavior should > be removed with a new policy, but no one has actually done that yet. See https://gitlab.kitware.com/cmake/cmake/issues/15208 for the actual issue for adding the policy. --Ben From egor.pugin at gmail.com Sat Dec 10 16:13:25 2016 From: egor.pugin at gmail.com (Egor Pugin) Date: Sun, 11 Dec 2016 00:13:25 +0300 Subject: [cmake-developers] Local target aliases Message-ID: Hi, It seems we don't have such feature at the moment. https://cmake.org/cmake/help/v3.7/command/add_library.html?highlight=add_library#alias-libraries Is it possible to add GLOBAL option as for INTERFACE/IMPORTED targets (lib/exe)? For consistency it's also possible to add GLOBAL for OBJECT libs. Goal as always is to not interfere with same alias names in other dirs. A new policy may be introduced for handling new behaviour. -- Egor Pugin From brad.king at kitware.com Mon Dec 12 10:37:27 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 12 Dec 2016 10:37:27 -0500 Subject: [cmake-developers] Local target aliases In-Reply-To: References: Message-ID: <24ee28f0-7abb-5367-5acb-cb7d88a1513f@kitware.com> On 12/10/2016 04:13 PM, Egor Pugin wrote: > Is it possible to add GLOBAL option as for INTERFACE/IMPORTED targets (lib/exe)? The GLOBAL option is only available with an IMPORTED target: https://cmake.org/cmake/help/v3.7/command/add_library.html#imported-libraries Non-imported targets are always globally visible. > For consistency it's also possible to add GLOBAL for OBJECT libs. OBJECT libraries are non-imported and therefore already GLOBAL. > Goal is to not interfere with same alias names in other dirs. The purpose of ALIAS targets is to allow in-project code to access a non-imported target through the same name as external code might access that target when it is imported. Since non-imported targets are always globally visible their names are not allowed to conflict anyway. -Brad From egor.pugin at gmail.com Mon Dec 12 11:35:31 2016 From: egor.pugin at gmail.com (Egor Pugin) Date: Mon, 12 Dec 2016 19:35:31 +0300 Subject: [cmake-developers] Local target aliases In-Reply-To: <24ee28f0-7abb-5367-5acb-cb7d88a1513f@kitware.com> References: <24ee28f0-7abb-5367-5acb-cb7d88a1513f@kitware.com> Message-ID: So, the original proposal is to make ALIAS & OBJECT targets local. And explicit GLOBAL keyword will make them global again. On 12 December 2016 at 18:37, Brad King wrote: > On 12/10/2016 04:13 PM, Egor Pugin wrote: >> Is it possible to add GLOBAL option as for INTERFACE/IMPORTED targets (lib/exe)? > > The GLOBAL option is only available with an IMPORTED target: > > https://cmake.org/cmake/help/v3.7/command/add_library.html#imported-libraries > > Non-imported targets are always globally visible. > >> For consistency it's also possible to add GLOBAL for OBJECT libs. > > OBJECT libraries are non-imported and therefore already GLOBAL. > >> Goal is to not interfere with same alias names in other dirs. > > The purpose of ALIAS targets is to allow in-project code to access a > non-imported target through the same name as external code might access > that target when it is imported. Since non-imported targets are always > globally visible their names are not allowed to conflict anyway. > > -Brad > -- Egor Pugin From Harry at codexdigital.com Mon Dec 12 11:51:05 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Mon, 12 Dec 2016 16:51:05 +0000 Subject: [cmake-developers] CPackProductbuild Scripts Message-ID: Hello, I am messing around with the CPackProductbuild stuff to try to port over what we had before. Currently it support undocumented options "CPACK_PREFLIGHT_SCRIPT", "CPACK_POSTFLIGHT_SCRIPT", "CPACK_PREFLIGHT__SCRIPT" and "CPACK_POSTFLIGHT__SCRIPT". It looks like these are also supported (also undocumented) in CPackPackageMaker. Are these options good names? Do they need to be these for ease of porting from Package Maker? Should they start with CPACK_PRODUCTBUILD_* as they are not generic? If the current names are fine I can prepare a pull req with documentation. Yours, Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 From brad.king at kitware.com Mon Dec 12 12:02:42 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 12 Dec 2016 12:02:42 -0500 Subject: [cmake-developers] Local target aliases In-Reply-To: References: <24ee28f0-7abb-5367-5acb-cb7d88a1513f@kitware.com> Message-ID: <7b154004-eae7-932b-3997-316176858f4f@kitware.com> On 12/12/2016 11:35 AM, Egor Pugin wrote: > So, the original proposal is to make ALIAS & OBJECT targets local. And > explicit GLOBAL keyword will make them global again. An OBJECT library is just like any other target as far as the generated build system is concerned, so it needs a globally unique name like any other. The purpose of ALIAS targets is this: ``` # some/subdir/CMakeLists.txt add_library(lib1 lib1.cpp) install(TARGETS lib1 EXPORT lib1Export ${dest_args}) install(EXPORT lib1Export NAMESPACE Upstream:: ${other_args}) add_library(Upstream::lib1 ALIAS lib1) ``` Then other code in the project can use the name `Upstream::lib1` as if it had imported that target (e.g. for test trees that may build inside the project or externally). The other code is not necessarily in the same directory, so the global visibility of ALIAS targets is an intentional design decision. Since the aliased target has a globally unique name, so would the ALIAS if it is only used to prefix a namespace. If your trees are so huge or import so many other third-party projects that name collisions are a problem, then I suggest breaking it down using ExternalProject. -Brad From clinton at elemtech.com Mon Dec 12 12:22:12 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 12 Dec 2016 10:22:12 -0700 (MST) Subject: [cmake-developers] CPackProductbuild Scripts In-Reply-To: References: Message-ID: <475583038.111140528.1481563332528.JavaMail.zimbra@elemtech.com> ----- On Dec 12, 2016, at 9:51 AM, Harry Mallon Harry at codexdigital.com wrote: > Hello, > > I am messing around with the CPackProductbuild stuff to try to port over what we > had before. Currently it support undocumented options > "CPACK_PREFLIGHT_SCRIPT", "CPACK_POSTFLIGHT_SCRIPT", > "CPACK_PREFLIGHT__SCRIPT" and "CPACK_POSTFLIGHT__SCRIPT". > It looks like these are also supported (also undocumented) in > CPackPackageMaker. Are these options good names? Do they need to be these for > ease of porting from Package Maker? Productbuild inherited those variables by factoring out common pkg support between PackageMaker and ProductBuild. I'm not aware of porting concerns, but I can imagine that being useful. I think there *are* people using the undocumented variables with PackageMaker. > Should they start with CPACK_PRODUCTBUILD_* > as they are not generic? The other CPack generators have their own variable names for this kind of thing. And they also have separate code to handle it. In this case, we have 2 pkg based generators with a potential of using the same named variables. With PackageMaker being deprecated, CPACK_PRODUCTBUILD_* sounds good. Clint > > If the current names are fine I can prepare a pull req with documentation. > > Yours, > Harry > > Harry Mallon > CODEX | Software Engineer > 60 Poland Street | London | England | W1F 7NT > E harry at codexdigital.com | T +44 203 7000 989 > -- > > 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: > http://public.kitware.com/mailman/listinfo/cmake-developers From egor.pugin at gmail.com Mon Dec 12 13:49:41 2016 From: egor.pugin at gmail.com (Egor Pugin) Date: Mon, 12 Dec 2016 21:49:41 +0300 Subject: [cmake-developers] Local target aliases In-Reply-To: <7b154004-eae7-932b-3997-316176858f4f@kitware.com> References: <24ee28f0-7abb-5367-5acb-cb7d88a1513f@kitware.com> <7b154004-eae7-932b-3997-316176858f4f@kitware.com> Message-ID: > If your trees are so huge or import so many other third-party projects that name collisions are a problem They are. I'm predicting possible collisions, but it's ok for now. > ... ExternalProject. Not much suitable. --- Ok, I'll try to do some workarounds. Thanks for the replies. On 12 December 2016 at 20:02, Brad King wrote: > On 12/12/2016 11:35 AM, Egor Pugin wrote: >> So, the original proposal is to make ALIAS & OBJECT targets local. And >> explicit GLOBAL keyword will make them global again. > > An OBJECT library is just like any other target as far as the generated > build system is concerned, so it needs a globally unique name like any > other. The purpose of ALIAS targets is this: > > ``` > # some/subdir/CMakeLists.txt > add_library(lib1 lib1.cpp) > install(TARGETS lib1 EXPORT lib1Export ${dest_args}) > install(EXPORT lib1Export NAMESPACE Upstream:: ${other_args}) > add_library(Upstream::lib1 ALIAS lib1) > ``` > > Then other code in the project can use the name `Upstream::lib1` as > if it had imported that target (e.g. for test trees that may build > inside the project or externally). The other code is not necessarily > in the same directory, so the global visibility of ALIAS targets is > an intentional design decision. Since the aliased target has a globally > unique name, so would the ALIAS if it is only used to prefix a namespace. > > If your trees are so huge or import so many other third-party projects > that name collisions are a problem, then I suggest breaking it down > using ExternalProject. > > -Brad -- Egor Pugin From irwin at beluga.phys.uvic.ca Mon Dec 12 20:26:08 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 12 Dec 2016 17:26:08 -0800 (PST) Subject: [cmake-developers] Tag signature with expired key Message-ID: Hi Brad: I attempted to verify a recent tag on the release branch with the following results: software at raven> git tag --verify v3.7.1 object db3499df5d06ab2cacc61e9f7720a33456aeafe4 type commit tag v3.7.1 tagger Brad King 1480522722 -0500 CMake 3.7.1 gpg: Signature made Wed 30 Nov 2016 08:18:42 AM PST using RSA key ID 34921684 gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: Good signature from "Brad King" gpg: aka "Brad King " gpg: aka "[jpeg image of size 4005]" gpg: Note: This key has expired! Primary key fingerprint: CBA2 3971 357C 2E65 90D9 EFD3 EC8F EF3A 7BFB 4EDA Subkey fingerprint: C6C2 6532 4BBE BDC3 50B5 13D0 2D2C EF10 3492 1684 error: could not verify the tag 'v3.7.1' software at raven> echo $? 1 I assume that error in an otherwise good tag signature is due to the fact your key has expired, but I thought it was impossible to sign with an expired key? Anyhow, I thought I should bring this signing by an expired key to your attention in case there is something going on here that you are not aware of. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). 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.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From eike at sf-mail.de Tue Dec 13 01:34:21 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 13 Dec 2016 07:34:21 +0100 Subject: [cmake-developers] Tag signature with expired key In-Reply-To: References: Message-ID: <1838378.KiQO1S272z@daneel.sf-tec.de> Am Montag, 12. Dezember 2016, 17:26:08 schrieb Alan W. Irwin: > Hi Brad: > > I attempted to verify a recent tag on the release branch with the > following results: > > software at raven> git tag --verify v3.7.1 > object db3499df5d06ab2cacc61e9f7720a33456aeafe4 > type commit > tag v3.7.1 > tagger Brad King 1480522722 -0500 > > CMake 3.7.1 > gpg: Signature made Wed 30 Nov 2016 08:18:42 AM PST using RSA key ID > 34921684 gpg: checking the trustdb > gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model > gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u > gpg: Good signature from "Brad King" > gpg: aka "Brad King " > gpg: aka "[jpeg image of size 4005]" > gpg: Note: This key has expired! > Primary key fingerprint: CBA2 3971 357C 2E65 90D9 EFD3 EC8F EF3A 7BFB 4EDA > Subkey fingerprint: C6C2 6532 4BBE BDC3 50B5 13D0 2D2C EF10 3492 1684 > error: could not verify the tag 'v3.7.1' > software at raven> echo $? > 1 > > I assume that error in an otherwise good tag signature is due to the > fact your key has expired, but I thought it was impossible to sign > with an expired key? Anyhow, I thought I should bring this signing by > an expired key to your attention in case there is something going on > here that you are not aware of. Speculation: the key was renewed locally, but those things have not been uploaded to the keyservers. Eikek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From irwin at beluga.phys.uvic.ca Tue Dec 13 02:26:23 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 12 Dec 2016 23:26:23 -0800 (PST) Subject: [cmake-developers] Tag signature with expired key In-Reply-To: <1838378.KiQO1S272z@daneel.sf-tec.de> References: <1838378.KiQO1S272z@daneel.sf-tec.de> Message-ID: > Speculation: the key was renewed locally, but those things have not been uploaded to the keyservers. Hi Eike: The explanation was similar to your above speculation but not quite. :-) I had not refreshed my local keyring from the keyservers recently. When I did that refresh (inspired by your speculation), the expired key "problem" was solved. So sorry for the noise, but nevertheless there is a useful gpg lesson to be learned here. After keys expire they can be renewed (which I didn't realize before) rather than having to generate a whole new key. So that means I (or anybody else) should always execute "gpg --refresh-keys" before complaining about expired keys! Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). 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.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From yves.frederix+cmake at gmail.com Wed Dec 14 15:26:13 2016 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Wed, 14 Dec 2016 21:26:13 +0100 Subject: [cmake-developers] Add native options to the clean step of 'cmake --build .. --clean-first' Message-ID: Hi all, In PR https://gitlab.kitware.com/cmake/cmake/merge_requests/329 I am suggesting to not only pass the additional/native build options to the actual build step, but also to the 'clean' step in case of a call like `cmake --build ... --clean-first`. The change is simple enough, but there is the risk that a 'make clean' does not accept the additional build options that for a normal build are ok, which could cause a build to fail. Hence, I would like to check with the devs on this list to judge the actual risk of this PR. Brad suggested to check the git logs to see if I could find something there. I tracked things down to d35651fb in which the additional build options were added.to the Build() function. It seems that already from the beginning, the additional options were only passed to the build step itself and not to the clean step. Whether there was a reason for this is unclear from the logs. My question now is whether somebody remembers if there indeed was a particular reason to leave out the additional options from the 'make clean' call? And if not, could you come up with a real example in which case the proposed change would cause a build failure? I have tried, but wasn't able to come up with anything, although I must admit that my view is limited as I do not have much experience with non-VS generators. Thanks. Yves From ben.boeckel at kitware.com Thu Dec 15 11:31:16 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 15 Dec 2016 11:31:16 -0500 Subject: [cmake-developers] Add native options to the clean step of 'cmake --build .. --clean-first' In-Reply-To: References: Message-ID: <20161215163116.GA28436@megas.kitware.com> On Wed, Dec 14, 2016 at 21:26:13 +0100, Yves Frederix wrote: > In PR https://gitlab.kitware.com/cmake/cmake/merge_requests/329 I am > suggesting to not only pass the additional/native build options to the > actual build step, but also to the 'clean' step in case of a call like > `cmake --build ... --clean-first`. The change is simple enough, but > there is the risk that a 'make clean' does not accept the additional > build options that for a normal build are ok, which could cause a > build to fail. Hence, I would like to check with the devs on this list > to judge the actual risk of this PR. > > Brad suggested to check the git logs to see if I could find something > there. I tracked things down to d35651fb in which the additional build > options were added.to the Build() function. It seems that already from > the beginning, the additional options were only passed to the build > step itself and not to the clean step. Whether there was a reason for > this is unclear from the logs. > > My question now is whether somebody remembers if there indeed was a > particular reason to leave out the additional options from the 'make > clean' call? And if not, could you come up with a real example in > which case the proposed change would cause a build failure? I have > tried, but wasn't able to come up with anything, although I must admit > that my view is limited as I do not have much experience with non-VS > generators. Flags for other generators can cause the `clean` to not actually happen. For example, with make `cmake --build ... --clean-first -- -i` can cause the clean to silently fail and then it isn't really a clean build. Or the `-t` flag which skips running commands and instead just touches output files. `-n` just prints what would be done. Or a target is passed and so you effectively have `make clean -j10 mytarget; make -j10 mytarget` which could be interesting with the `mytarget` subgraph making files while `clean` is going around deleting them again. IMO, these flags being passed to `--clean-first`'s subtask can completely invalidate what is being asked for and it makes sense that `--clean-first` is really just a plain clean. --Ben From kim.walisch at gmail.com Thu Dec 15 11:54:58 2016 From: kim.walisch at gmail.com (Kim Walisch) Date: Thu, 15 Dec 2016 17:54:58 +0100 Subject: [cmake-developers] CMake vs libtool versioning of shared libraries Message-ID: Hi, I am currently in the process of switching the build system of my primecount project from Autotools to CMake and the shared library versioning in CMake is not yet clear to myself. My current project version (API version) is 3.5 and the libtool version (ABI version) is 4:7:0. So I have set the VERSION and SOVERSION to my libtool version (in CMakeLists.txt): set_target_properties(libprimecount PROPERTIES SOVERSION 4) set_target_properties(libprimecount PROPERTIES VERSION "4.7.0") Is this correct? Or should I set the VERSION to my current project version (API version): set_target_properties(libprimecount PROPERTIES SOVERSION 4) set_target_properties(libprimecount PROPERTIES VERSION "3.5") Best regards, Kim From brad.king at kitware.com Thu Dec 15 13:07:39 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 15 Dec 2016 13:07:39 -0500 Subject: [cmake-developers] CMake vs libtool versioning of shared libraries In-Reply-To: References: Message-ID: On 12/15/2016 11:54 AM, Kim Walisch wrote: > I am currently in the process of switching the build system of my > primecount project from Autotools to CMake and the shared library > versioning in CMake is not yet clear to myself. My current project > version (API version) is 3.5 and the libtool version (ABI version) is > 4:7:0. So I have set the VERSION and SOVERSION to my libtool > version (in CMakeLists.txt): > > set_target_properties(libprimecount PROPERTIES SOVERSION 4) > set_target_properties(libprimecount PROPERTIES VERSION "4.7.0") > > Is this correct? Or should I set the VERSION to my current project > version (API version): > > set_target_properties(libprimecount PROPERTIES SOVERSION 4) > set_target_properties(libprimecount PROPERTIES VERSION "3.5") The CMake properties give direct control over the way the files are constructed: libfoo.so -> libfoo.so.$soversion libfoo.so.$soversion -> libfoo.so.$version libfoo.so.$version (actual file) Libtool instead defines version components [1] "current", "revision", and "age", and somehow maps them to the version and soversion above. I don't recall the mapping off the top of my head, but if you want to reproduce what you were doing before you should do that mapping to select the values for the CMake SOVERSION and VERSION properties. -Brad [1] https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html From kim.walisch at gmail.com Thu Dec 15 13:57:40 2016 From: kim.walisch at gmail.com (Kim Walisch) Date: Thu, 15 Dec 2016 19:57:40 +0100 Subject: [cmake-developers] CMake vs libtool versioning of shared libraries In-Reply-To: References: Message-ID: Thanks for your answer. Lets suppose I do not want to stick to my previous libtool versioning but instead version my library according to cmake best practices. How should I set VERSION and SOVERSION given my API version is 3.5 and my old ABI version 4:7:0. By browsing a few CMakeLists.txt on GitHub of other projects it seems to me that most of these projects set VERSION to the project/API version (e.g. 3.5) and the SOVERSION to the project/API major version (e.g 3). -Kim On Thu, Dec 15, 2016 at 7:07 PM, Brad King wrote: > On 12/15/2016 11:54 AM, Kim Walisch wrote: >> I am currently in the process of switching the build system of my >> primecount project from Autotools to CMake and the shared library >> versioning in CMake is not yet clear to myself. My current project >> version (API version) is 3.5 and the libtool version (ABI version) is >> 4:7:0. So I have set the VERSION and SOVERSION to my libtool >> version (in CMakeLists.txt): >> >> set_target_properties(libprimecount PROPERTIES SOVERSION 4) >> set_target_properties(libprimecount PROPERTIES VERSION "4.7.0") >> >> Is this correct? Or should I set the VERSION to my current project >> version (API version): >> >> set_target_properties(libprimecount PROPERTIES SOVERSION 4) >> set_target_properties(libprimecount PROPERTIES VERSION "3.5") > > The CMake properties give direct control over the way the files > are constructed: > > libfoo.so -> libfoo.so.$soversion > libfoo.so.$soversion -> libfoo.so.$version > libfoo.so.$version (actual file) > > Libtool instead defines version components [1] "current", "revision", > and "age", and somehow maps them to the version and soversion above. > I don't recall the mapping off the top of my head, but if you want to > reproduce what you were doing before you should do that mapping to > select the values for the CMake SOVERSION and VERSION properties. > > -Brad > > [1] https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html > From brad.king at kitware.com Thu Dec 15 14:08:35 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 15 Dec 2016 14:08:35 -0500 Subject: [cmake-developers] CMake vs libtool versioning of shared libraries In-Reply-To: References: Message-ID: <3ca20e80-2a8e-6768-e6fc-064ad359f75e@kitware.com> On 12/15/2016 01:57 PM, Kim Walisch wrote: > Lets suppose I do not want to stick to my previous libtool versioning > but instead version my library according to cmake best practices. How > should I set VERSION and SOVERSION given my API version is 3.5 and my > old ABI version 4:7:0. By browsing a few CMakeLists.txt on GitHub of > other projects it seems to me that most of these projects set VERSION > to the project/API version (e.g. 3.5) and the SOVERSION to the > project/API major version (e.g 3). The VERSION is only for human reference and so can be the project version or anything else. The SOVERSION is what provides the API version level. A binary linked to your library will at runtime look for "libfoo.so.$soversion", and any file the dynamic loader can find with that name is considered acceptable. Therefore the SOVERSION should be used for API versioning. If you remove an API then the soversion should be changed. The project version and API version don't have to be related, but it is a common convention depending on API stability. -Brad From ben.boeckel at kitware.com Thu Dec 15 14:28:13 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 15 Dec 2016 14:28:13 -0500 Subject: [cmake-developers] CMake vs libtool versioning of shared libraries In-Reply-To: <3ca20e80-2a8e-6768-e6fc-064ad359f75e@kitware.com> References: <3ca20e80-2a8e-6768-e6fc-064ad359f75e@kitware.com> Message-ID: <20161215192813.GA4264@megas.kitware.com> On Thu, Dec 15, 2016 at 14:08:35 -0500, Brad King wrote: > On 12/15/2016 01:57 PM, Kim Walisch wrote: > > Lets suppose I do not want to stick to my previous libtool versioning > > but instead version my library according to cmake best practices. How > > should I set VERSION and SOVERSION given my API version is 3.5 and my > > old ABI version 4:7:0. By browsing a few CMakeLists.txt on GitHub of > > other projects it seems to me that most of these projects set VERSION > > to the project/API version (e.g. 3.5) and the SOVERSION to the > > project/API major version (e.g 3). > > The VERSION is only for human reference and so can be the project > version or anything else. The SOVERSION is what provides the > API version level. A binary linked to your library will at runtime > look for "libfoo.so.$soversion", and any file the dynamic loader > can find with that name is considered acceptable. Therefore the > SOVERSION should be used for API versioning. If you remove an > API then the soversion should be changed. > > The project version and API version don't have to be related, > but it is a common convention depending on API stability. Note that this is actually ABI compatibility, not API (i.e., source-level) compatibility. Adding virtual methods, reordering struct members, changing struct sizes, etc. all require a SOVERSION bump upon release, but are not necessarily API breaks. KDE has a list of things which change the ABI for C++ here: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B It does not look to have been updated for C++11, so things which affect `auto` deduction may also cause ABI incompatibilities. --Ben From yves.frederix+cmake at gmail.com Fri Dec 16 03:46:22 2016 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Fri, 16 Dec 2016 09:46:22 +0100 Subject: [cmake-developers] Add native options to the clean step of 'cmake --build .. --clean-first' In-Reply-To: <20161215163116.GA28436@megas.kitware.com> References: <20161215163116.GA28436@megas.kitware.com> Message-ID: > Flags for other generators can cause the `clean` to not actually happen. > For example, with make `cmake --build ... --clean-first -- -i` can cause > the clean to silently fail and then it isn't really a clean build. Or > the `-t` flag which skips running commands and instead just touches > output files. `-n` just prints what would be done. Or a target is passed > and so you effectively have `make clean -j10 mytarget; make -j10 > mytarget` which could be interesting with the `mytarget` subgraph making > files while `clean` is going around deleting them again. Although I am not fully convinced that the above might actually happen in 'normal' practice, I do agree that it is a risk that should not be introduced simply to get less verbose output for the clean step (my use case). Pulling the PR ;) Thanks for your insights! Regards, Yves > > IMO, these flags being passed to `--clean-first`'s subtask can > completely invalidate what is being asked for and it makes sense that > `--clean-first` is really just a plain clean. > > --Ben From joubert.sy at gmail.com Fri Dec 16 04:35:03 2016 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Fri, 16 Dec 2016 10:35:03 +0100 Subject: [cmake-developers] Disabling leaks check when using Address Sanitizer Message-ID: Hi everyone, I've setup some sanitizer builds on my project and I'd like to have two separate builds for asan and lsan, meaning I want to disable leak detection in the asan build. I've managed to correctly setup the CTEST_MEMORYCHECK_SANITIZER_OPTIONS with "detect_leaks=0" and at runtime (ctest_memcheck) the ASAN_OPTIONS is populated with my custom value. The issue is that CMake appends its own "detect_leak=1" (while "log_file=..." is prepended). It overrides my own option which has then no effect. I see two possible fixes here: 1- Since "detect_leaks=1" is the default, we can simply not append it to the options and make sure the user options are last 2- If we still want to explicitly set "detect_leaks=1", I'd suggest to prepend it, like "log_file=", to the user options so that anyone can override them if need be The related code seems to be at: 25d7b883 : Source/CTest/cmCTestMemCheckHandler.cxx:600 If my analysis is correct I can make a MR. Which fixes would you prefer? Regards, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Dec 16 07:55:59 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 16 Dec 2016 07:55:59 -0500 Subject: [cmake-developers] Disabling leaks check when using Address Sanitizer In-Reply-To: References: Message-ID: On 12/16/2016 04:35 AM, Sylvain Joubert wrote: > The issue is that CMake appends its own "detect_leak=1" > > I see two possible fixes here: > 1- Since "detect_leaks=1" is the default, we can simply not append > it to the options and make sure the user options are last It looks like this was added in commit 44726714322ca0b75628e234229f4583a480d7ec when support for asan was first added. Bill, do you recall why? > If my analysis is correct I can make a MR. Which fixes would you prefer? A MR would be fine, thanks! -Brad From brad.king at kitware.com Fri Dec 16 07:57:40 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 16 Dec 2016 07:57:40 -0500 Subject: [cmake-developers] Maintainer vacation until Jan 9 Message-ID: Hi Folks, FYI, after today I'm heading out for vacation and will likely not be responsive until at least Jan 9. -Brad From ben.boeckel at kitware.com Fri Dec 16 08:57:01 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 16 Dec 2016 08:57:01 -0500 Subject: [cmake-developers] Add native options to the clean step of 'cmake --build .. --clean-first' In-Reply-To: References: <20161215163116.GA28436@megas.kitware.com> Message-ID: <20161216135701.GA19163@megas.kitware.com> On Fri, Dec 16, 2016 at 09:46:22 +0100, Yves Frederix wrote: > Although I am not fully convinced that the above might actually happen > in 'normal' practice, I do agree that it is a risk that should not be > introduced simply to get less verbose output for the clean step (my > use case). Pulling the PR ;) Thanks for your insights! If that is what you want, a `clean-quiet` target might be more useful which then uses generator-specific flags. This could even be a separate `--quiet` flag for `cmake --build` which would then apply to both the build and clean step. --Ben From bill.hoffman at kitware.com Fri Dec 16 11:25:44 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 16 Dec 2016 11:25:44 -0500 Subject: [cmake-developers] Disabling leaks check when using Address Sanitizer In-Reply-To: References: Message-ID: On 12/16/2016 7:55 AM, Brad King wrote: > It looks like this was added in commit 44726714322ca0b75628e234229f4583a480d7ec > when support for asan was first added. Bill, do you recall why? I don't recall exactly. I guess I figured if you were running asan you might as well check for leaks as well. Maybe the right fix is to have user flags over ride anything CMake adds, but leave the default like it is. -Bill From domen.vrankar at gmail.com Tue Dec 20 11:50:02 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Tue, 20 Dec 2016 17:50:02 +0100 Subject: [cmake-developers] not able to push topic to stage Message-ID: Hi, Has anything changed regarding how topics should be pushed to stage and then to next for testing? When following what's written here: https://cmake.org/Wiki/CMake/Git/Develop I get a git hook error: remote: ---------------------------------------------------------------------- remote: denying cpack-deb-version-override-fix (64e9c38d) which contains deny/topics/next (66805932) remote: ---------------------------------------------------------------------- remote: error: hook declined to update refs/heads/cpack-deb-version-override-fix To cmake.org:stage/cmake.git ! [remote rejected] HEAD -> cpack-deb-version-override-fix (hook declined) error: failed to push some refs to 'git at cmake.org:stage/cmake.git' Thanks, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Dec 20 12:02:15 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 20 Dec 2016 12:02:15 -0500 Subject: [cmake-developers] not able to push topic to stage In-Reply-To: References: Message-ID: <20161220170215.GA27613@megas.kitware.com> On Tue, Dec 20, 2016 at 17:50:02 +0100, Domen Vrankar wrote: > Has anything changed regarding how topics should be pushed to stage and > then to next for testing? > > When following what's written here: https://cmake.org/Wiki/CMake/Git/Develop > I get a git hook error: > > remote: > ---------------------------------------------------------------------- > remote: denying cpack-deb-version-override-fix (64e9c38d) which contains > deny/topics/next (66805932) > remote: Your branch contains `next` in it. This is not allowed since your branch would then bring in all of the history `next` has into `master`. Are you trying to update your topic on `next`? Or base your branch on top of something on on `next`? --Ben From domen.vrankar at gmail.com Tue Dec 20 13:49:19 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Tue, 20 Dec 2016 19:49:19 +0100 Subject: [cmake-developers] not able to push topic to stage In-Reply-To: <20161220170215.GA27613@megas.kitware.com> References: <20161220170215.GA27613@megas.kitware.com> Message-ID: 2016-12-20 18:02 GMT+01:00 Ben Boeckel : > On Tue, Dec 20, 2016 at 17:50:02 +0100, Domen Vrankar wrote: > > Has anything changed regarding how topics should be pushed to stage and > > then to next for testing? > > > > When following what's written here: https://cmake.org/Wiki/CMake/ > Git/Develop > > I get a git hook error: > > > > remote: > > ---------------------------------------------------------------------- > > remote: denying cpack-deb-version-override-fix (64e9c38d) which contains > > deny/topics/next (66805932) > > remote: > > Your branch contains `next` in it. This is not allowed since your branch > would then bring in all of the history `next` has into `master`. > > Are you trying to update your topic on `next`? Or base your branch on > top of something on on `next`? > Oh... My mistake... Not certain how I managed to start from that branch. Thanks, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.samimi.tech at gmail.com Wed Dec 21 07:00:29 2016 From: p.samimi.tech at gmail.com (Payam Samimi) Date: Wed, 21 Dec 2016 13:00:29 +0100 Subject: [cmake-developers] import another compiler to cmake Message-ID: Hi everybody, I'm working for a big company in Germany as software developer. They develope their code and test modules in c++ and using CMake. Additionally they use their own compiler which is company specific and they would like import or connect their own compiler to CMake, that Cmake can use it. So, this is my task, and I would like to ask you whether you have any suggestion that could help me. regards, Payam -------------- next part -------------- An HTML attachment was scrubbed... URL: From florent.castelli at gmail.com Wed Dec 21 07:12:40 2016 From: florent.castelli at gmail.com (Florent Castelli) Date: Wed, 21 Dec 2016 13:12:40 +0100 Subject: [cmake-developers] Unknown Imported & Global libraries Message-ID: <12897DE5-1416-4336-8568-219AD7447491@gmail.com> Hi, In my project, I have to deal with 3rd party libraries. Either the library is available on the system and then I will try to use that, or I will use sources bundled in my repository. This is in order to make Linux maintainers happy who want to have a system-wide shared library, but to also keep a self contained build available by default. But all that logic is cumbersome, so it usually ends up in a dedicated file looking like: find_package(foo) if(NOT FOO_FOUND) add_library(foo STATIC foo.cpp) endif() Then with modern CMake, you don?t just get variables but imported targets, usually defined with something like: add_library(FOO::FOO UNKNOWN IMPORTED) All those scripts being used through multiple levels of add_subdirectory() calls, makes it so that the imported targets are only scoped to the leaf file and not visible to the other libraries that may want to use it. One way to work around that would be to mark them GLOBAL. But the problem is that I then get an error such as: CMake Error at CMakeLists.txt:1533 (target_link_libraries): Target ?FOO::FOO" of type UNKNOWN_LIBRARY may not be linked into another target. One may link only to STATIC or SHARED libraries, or to executables with the ENABLE_EXPORTS property set. Without the GLOBAL keyword, it links just fine (as long as I keep the definition in the same scope). So why would GLOBAL trigger a different behaviour? Any ideas why that would be? I went through the code quickly, but I didn?t find anything relevant, so I?m quite puzzled. I know I could use instead include() instead of add_subdirectory() to go through the external dependencies but I believe that?s a wrong fix. Scoping variables is actually nice. Also, I would very much desire a setting to make imported libraries global by default to increase the legibility of most code and avoid having huge CMake scripts as most people currently do. Splitting targets in different files should be the norm! I can also override add_library to add the GLOBAL keyword automatically, which would work if UNKNOWN IMPORTED GLOBAL was actually working... /Florent From ben.boeckel at kitware.com Wed Dec 21 09:31:33 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 21 Dec 2016 09:31:33 -0500 Subject: [cmake-developers] import another compiler to cmake In-Reply-To: References: Message-ID: <20161221143133.GB2863@megas.kitware.com> On Wed, Dec 21, 2016 at 13:00:29 +0100, Payam Samimi wrote: > I'm working for a big company in Germany as software developer. They > develope their code and test modules in c++ and using CMake. Additionally > they use their own compiler which is company specific and they would like > import or connect their own compiler to CMake, that Cmake can use it. So, > this is my task, and I would like to ask you whether you have any > suggestion that could help me. Adding a compiler to CMake is possible, but in order to ensure that it continues to work, a nightly dashboard would be helpful to catch any problems changes introduce for the compiler. Instructions for setting up a dashboard are here: https://cmake.org/Wiki/CMake/Git/Dashboard To actually add support, it would need to be added to the detection logic under the `Modules/Compiler` directory and to the `Modules/CMakeCompilerIdDetection.cmake` module. Docs would also be necessary. There also may be more, but that is a minimum. Brad knows much more, but is currently on vacation until the second week in January. Thanks, --Ben From konstantin at podsvirov.pro Sat Dec 24 07:01:26 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Sat, 24 Dec 2016 15:01:26 +0300 Subject: [cmake-developers] Allow CodeBlocks for NMake Makefiles JOM Message-ID: <1205181482580886@web10o.yandex.ru> An HTML attachment was scrubbed... URL: From konstantin at podsvirov.pro Sun Dec 25 13:42:38 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Sun, 25 Dec 2016 21:42:38 +0300 Subject: [cmake-developers] =?utf-8?q?=E2=80=8BQt_Creator_vs_CMake_server_?= =?utf-8?q?mode?= Message-ID: <980831482691358@web19m.yandex.ru> An HTML attachment was scrubbed... URL: From debuggery at outlook.com Mon Dec 26 19:05:32 2016 From: debuggery at outlook.com (Karl Robinson) Date: Tue, 27 Dec 2016 00:05:32 +0000 Subject: [cmake-developers] Fw: CTest and Address Sanitizer In-Reply-To: References: Message-ID: Hi I am trying to use Address Sanitizer (also UndefinedBehaviour and Memory Sanitizers) with CTest (CMake 3.5.1). ?In my top level cmake file I have set(MEMORYCHECK_TYPE "AddressSanitizer")? include (CTest) enable_testing() add_test( some_test_case?) Then I run my tests with? ? ? ? ? ctest -T memcheck Whatever I do I always end up with Valgrind being run, occasionally (depending on what I have been messing with) CTest reports "Memory checker (MemoryCheckCommand) not set, or cannot find the specified program.") In both cases my Dart config file looks like this # Dynamic analysis (MemCheck) PurifyCommand: ValgrindCommand: ValgrindCommandOptions: MemoryCheckType: AddressSanitizer MemoryCheckSanitizerOptions: MemoryCheckCommand: /usr/bin/valgrind MemoryCheckCommandOptions: MemoryCheckSuppressionFile: When I look through the cmake source code it seems that setting the MEMORYCHECK_TYPE variable to?AddressSanitizer but?with no?MEMORYCHECK_COMMAND specified is correct. Why do I always end up with Valgrind being selected? Is this the?correct behavior? When I run 'ctest -T test' on code built with a sanitizer enabled I can see bugs in the code firing the sanitizer and useful output is produced. So I don't understand why ?Valgrind is required The reason for trying to do this is that I was hoping that when I run a memcheck?ctest would see the output from the sanitizers and mark the test case as failed. However, neither 'test' nor 'memcheck' detect the sanitizer failure Any ideas what I might be doing wrong? Better, is there an example of using the sanitizers with ctest? CMake & CTest are great tools but would be even more awesome if I could integrate CTest and the sanitizers Thanks! From rleigh at codelibre.net Tue Dec 27 07:20:17 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 27 Dec 2016 12:20:17 +0000 Subject: [cmake-developers] Boost 1.63 support Message-ID: <17d22622-46f6-eaf8-84cf-d2e79147798d@codelibre.net> I opened the following merge request to add support for the newly-released Boost 1.63: https://gitlab.kitware.com/cmake/cmake/merge_requests/361 Kind regards, Roger From gjasny at googlemail.com Tue Dec 27 09:34:32 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 27 Dec 2016 15:34:32 +0100 Subject: [cmake-developers] Boost 1.63 support In-Reply-To: <17d22622-46f6-eaf8-84cf-d2e79147798d@codelibre.net> References: <17d22622-46f6-eaf8-84cf-d2e79147798d@codelibre.net> Message-ID: <2363b813-812a-c551-9679-ad775c5ae5f5@googlemail.com> Hello, On 27/12/2016 13:20, Roger Leigh wrote: > I opened the following merge request to add support for the > newly-released Boost 1.63: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/361 I wonder what's the reason for stating explicitly all the released versions? It they are necessary at all, couldn't they be added in speculative batches of 10 or so? Thanks, Gregor From rleigh at codelibre.net Tue Dec 27 11:09:38 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 27 Dec 2016 16:09:38 +0000 Subject: [cmake-developers] Boost 1.63 support In-Reply-To: <2363b813-812a-c551-9679-ad775c5ae5f5@googlemail.com> References: <17d22622-46f6-eaf8-84cf-d2e79147798d@codelibre.net> <2363b813-812a-c551-9679-ad775c5ae5f5@googlemail.com> Message-ID: On 27/12/2016 14:34, Gregor Jasny via cmake-developers wrote: > Hello, > > On 27/12/2016 13:20, Roger Leigh wrote: >> I opened the following merge request to add support for the >> newly-released Boost 1.63: >> >> https://gitlab.kitware.com/cmake/cmake/merge_requests/361 > > I wonder what's the reason for stating explicitly all the released > versions? It they are necessary at all, couldn't they be added in > speculative batches of 10 or so? It would certainly be possible to add additional versions ahead of time. What would be more difficult are the component dependencies, which are needed for the imported targets. That said, the dependency introspection script can compute these on the fly, at the expense of taking several minutes to grind through all the sources and headers. We could potentially fall back to computing them if the embedded dependency information is missing, though it does make assumptions about the autolink macros in the headers--if they ever changed then it would need updating. Fundamentally, the current approach is an overly complicated hack to work around the fact that Boost has never exported this information in a form consumable by any build system, leading to projects hardcoding all this information (or doing it in a single place as here). Regards, Roger From gjasny at googlemail.com Tue Dec 27 11:14:30 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 27 Dec 2016 17:14:30 +0100 Subject: [cmake-developers] Do all non-Windows host platforms support uname(3) Message-ID: Hello, recently I realized that most pre-defined CMake variables are not available in scripting context. In my use case I had to identify a Linux host system. Unfortunately only CMAKE_HOST_{APPLE,SOLARIS,UNIX,WIN32} are available in scripting context. I wondered if all supported host operating systems support the uname(3) function call? If yes we could also make CMAKE_HOST_SYSTEM_NAME in scripting context. A proof-of-concept patch is located here: https://gitlab.kitware.com/gjasny/cmake/commits/cmake-host-system-name Thanks, Gregor From xavier.besseron at uni.lu Thu Dec 29 04:56:31 2016 From: xavier.besseron at uni.lu (Xavier Besseron) Date: Thu, 29 Dec 2016 10:56:31 +0100 Subject: [cmake-developers] Fw: CTest and Address Sanitizer In-Reply-To: References: Message-ID: Hi Karl, Maybe this blog post can be useful to you: https://blog.kitware.com/ctest-cdash-add-support-for-new-dynamic-analysis-tools/ I believe that the AddressSanitizer should normally stop with a non-zero error code right after the first error. You can check the runtime flags to control this behavior: https://github.com/google/sanitizers/wiki/AddressSanitizerFlags https://github.com/google/sanitizers/wiki/SanitizerCommonFlags Best regards, Xavier On Tue, Dec 27, 2016 at 1:05 AM, Karl Robinson wrote: > Hi > > I am trying to use Address Sanitizer (also UndefinedBehaviour and Memory > Sanitizers) with CTest (CMake 3.5.1). In my top level cmake file I have > > set(MEMORYCHECK_TYPE "AddressSanitizer") > include (CTest) > enable_testing() > add_test( some_test_case ) > > Then I run my tests with > > ctest -T memcheck > > > Whatever I do I always end up with Valgrind being run, occasionally > (depending on what I have been messing with) CTest reports "Memory checker > (MemoryCheckCommand) not set, or cannot find the specified program.") > > In both cases my Dart config file looks like this > > # Dynamic analysis (MemCheck) > PurifyCommand: > ValgrindCommand: > ValgrindCommandOptions: > MemoryCheckType: AddressSanitizer > MemoryCheckSanitizerOptions: > MemoryCheckCommand: /usr/bin/valgrind > MemoryCheckCommandOptions: > MemoryCheckSuppressionFile: > > When I look through the cmake source code it seems that setting the > MEMORYCHECK_TYPE variable to AddressSanitizer but with > no MEMORYCHECK_COMMAND specified is correct. Why do I always end up with > Valgrind being selected? Is this the correct behavior? > > When I run 'ctest -T test' on code built with a sanitizer enabled I can > see bugs in the code firing the sanitizer and useful output is produced. So > I don't understand why Valgrind is required > > The reason for trying to do this is that I was hoping that when I run a > memcheck ctest would see the output from the sanitizers and mark the test > case as failed. However, neither 'test' nor 'memcheck' detect the sanitizer > failure > > Any ideas what I might be doing wrong? Better, is there an example of > using the sanitizers with ctest? > > CMake & CTest are great tools but would be even more awesome if I could > integrate CTest and the sanitizers > > Thanks! > > > -- > > 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: > http://public.kitware.com/mailman/listinfo/cmake-developers > -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Kirchberg, Office E-007 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Thu Dec 29 14:40:03 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Thu, 29 Dec 2016 20:40:03 +0100 Subject: [cmake-developers] require-tr1 topic Message-ID: <6961e67d-7cc7-eff7-a0c4-16838c3cd1d0@googlemail.com> Hello Daniel, I wonder what's the idea behind the require-tr1 topic? Some still supported platforms like macOS with Xcode 3.x seem to fail now. Thanks, Gregor From debuggery at outlook.com Thu Dec 29 15:33:28 2016 From: debuggery at outlook.com (Karl Robinson) Date: Thu, 29 Dec 2016 20:33:28 +0000 Subject: [cmake-developers] Fw: CTest and Address Sanitizer In-Reply-To: References: , Message-ID: >> Maybe this blog post can be useful to you: https://blog.kitware.com/ctest-cdash-add-support-for-new-dynamic-analysis-tools/ Thanks?Xavier, I did stumble across that blog post previously. It doesn't really help with my problem though.? >> I believe that the AddressSanitizer should normally stop with a non-zero error code right after the first error. I have many tests within each executable test application, forcing the application to exit on the first error is not optimal since it means I cannot get an overview?of all the issues and triage/fix them?in logical order. Instead I have to test/fix/retest every time I should make some experiments with Valgrind, iirc ctest does understand Valgrind output. Of course, I already fixed all the issues?Valgrind detected so now I have to fabri-cobble some new ones #? I guess no one knows why Valgrind always seems to run when memtest is selected? Thanks again for taking the time! On Tue, Dec 27, 2016 at 1:05 AM, Karl Robinson wrote: Hi I am trying to use Address Sanitizer (also UndefinedBehaviour and Memory Sanitizers) with CTest (CMake 3.5.1).? In my top level cmake file I have set(MEMORYCHECK_TYPE "AddressSanitizer")? include (CTest) enable_testing() add_test( some_test_case?) Then I run my tests with? ? ? ? ? ctest -T memcheck Whatever I do I always end up with Valgrind being run, occasionally (depending on what I have been messing with) CTest reports "Memory checker (MemoryCheckCommand) not set, or cannot find the specified program.") In both cases my Dart config file looks like this # Dynamic analysis (MemCheck) PurifyCommand: ValgrindCommand: ValgrindCommandOptions: MemoryCheckType: AddressSanitizer MemoryCheckSanitizerOptions: MemoryCheckCommand: /usr/bin/valgrind MemoryCheckCommandOptions: MemoryCheckSuppressionFile: When I look through the cmake source code it seems that setting the MEMORYCHECK_TYPE variable to?AddressSanitizer but?with no?MEMORYCHECK_COMMAND specified is correct. Why do? I always end up with Valgrind being selected? Is this the?correct behavior? When I run 'ctest -T test' on code built with a sanitizer enabled I can see bugs in the code firing the sanitizer and useful output is produced. So I don't understand why ?Valgrind is required The reason for trying to do this is that I was hoping that when I run a memcheck?ctest would see the output from the sanitizers and mark the test case as failed. However, neither 'test' nor 'memcheck' detect the sanitizer failure Any ideas what I might be doing wrong? Better, is there an example of using the sanitizers with ctest? CMake & CTest are great tools but would be even more awesome if I could integrate CTest and the sanitizers Thanks! -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Kirchberg, Office E-007 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OutlookEmoji-&#X00023?.png Type: image/png Size: 335 bytes Desc: OutlookEmoji-&#X00023?.png URL: From daniel at pfeifer-mail.de Thu Dec 29 16:35:57 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 29 Dec 2016 22:35:57 +0100 Subject: [cmake-developers] require-tr1 topic In-Reply-To: <6961e67d-7cc7-eff7-a0c4-16838c3cd1d0@googlemail.com> References: <6961e67d-7cc7-eff7-a0c4-16838c3cd1d0@googlemail.com> Message-ID: On Thu, Dec 29, 2016 at 8:40 PM, Gregor Jasny wrote: > Hello Daniel, > > I wonder what's the idea behind the require-tr1 topic? Some still > supported platforms like macOS with Xcode 3.x seem to fail now. > Hi Gregor, I just wanted to test the availability of tr1 libraries on still supported platforms on a nightly build. I did expect this to fail on many platforms, that's why I did this during the holidays. I am actually surprised by the number of builds that did not fail! I have now the information that I wanted so I reverted the topic. I will write more details to the dev mailing list soon. Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: