[cmake-developers] Review Request: Topic ExternalProject_labels
Hello all, Please review the topic ExternalProject_labels. --- ExternalProject: Set LABELS property to targets his is useful for using CDash subprojects. http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=8810ddb3b710abf222f23ae96ac025beae63d812 --- ExternalProject: Set FOLDER property to targets This is useful when using the USE_FOLDERS global property http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=f7c7f02e47c3648c70fbad2708f4b19835b623b2 Thanks, Daniele -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review Request: Topic ExternalProject_labels
ExternalProject: Set LABELS property to targets his is useful for using CDash subprojects. ExternalProject: Set FOLDER property to targets This is useful when using the USE_FOLDERS global property Seems like something this simple is not quite flexible enough to make it worthwhile. You could do the same thing with set_property calls in your own code immediately after an ExternalProject_Add. If we go to the trouble to actually incorporate this into ExternalProject, shouldn't we make it flexible, so that callers can pass in LABELS of their choice, and a FOLDER name of their choice? Simply hard-coding it to the name of the project, and the string ExternalProjectTargets may make it possible to organize, but not everybody will be happy with the resulting names and organization. I think if we're going to add something like this to EP, it should be flexible enough to allow LABELS and FOLDER values to be passed in from the caller. David C. -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake identifies MacOSX10.7-Xcode43-ub as GNU, but it runs clang.
On 04/28/2014 01:07 PM, Brad King wrote: It looks like in this case users will have to tell Xcode what tool to use up front using the CMake generator toolset feature (cmake -T). I think this is acceptable because it only affects old Xcode versions. Otherwise we will need a much more complicated compiler id bootstrap process Actually it is not so complicated because the determination of the sysroot and deployment target does not depend on the language. I just had to introduce a platform-specific initialization step after the system is determined but before the compilers are: Add platform-specific initialization step when enabling languages http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=416761e3 OS X: Factor a Darwin-Initialize module out of Platform/Darwin http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0200d0a9 Xcode: Use sysroot and deployment target to identify compiler http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0cce556b Now the Xcode compiler identification finds the right one. I've reverted my change to the machine-specific dashboard script. -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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake identifies MacOSX10.7-Xcode43-ub as GNU, but it runs clang.
On Tuesday, April 29, 2014 11:01:06 AM Brad King wrote: On 04/28/2014 01:07 PM, Brad King wrote: It looks like in this case users will have to tell Xcode what tool to use up front using the CMake generator toolset feature (cmake -T). I think this is acceptable because it only affects old Xcode versions. Otherwise we will need a much more complicated compiler id bootstrap process Actually it is not so complicated because the determination of the sysroot and deployment target does not depend on the language. I just had to introduce a platform-specific initialization step after the system is determined but before the compilers are: Add platform-specific initialization step when enabling languages http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=416761e3 OS X: Factor a Darwin-Initialize module out of Platform/Darwin http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0200d0a9 Xcode: Use sysroot and deployment target to identify compiler http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0cce556b Now the Xcode compiler identification finds the right one. I've reverted my change to the machine-specific dashboard script. -Brad Thanks! Those fixes were needed to fix this: http://cmake.org/Bug/view.php?id=14572 - Clint -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMP0043 warnings everywhere
On Monday, April 28, 2014 10:26:56 James Bigler wrote: -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Brad King Sent: Wednesday, April 23, 2014 11:06 AM To: cmake-developers@cmake.org Subject: Re: [cmake-developers] CMP0043 warnings everywhere On 04/23/2014 12:57 PM, James Bigler wrote: I'm getting tons of CMP0043 warnings on my existing project. I have cmake_policy(VERSION 2.6) set in my project. Why am I being pestered by warnings? Shouldn't I get a policy value appropriate for 2.6 (so CMP0043 should be set to OLD)? Setting policies by VERSION leaves policies newer than that version unset, not set to OLD. If it were to set them to OLD then no new policies would ever warn. There is intentionally no way to turn off warnings about policies newer than those known to the project code, except by using -Wno-dev locally. Otherwise developers would never see the warnings and know to update their code. I thought the purpose of policies was to keep some backward compatibility feature, but allow users to select the new behavior. In this case, setting the behavior for new policies to OLD seems the most logical, especially when I asked for it with cmake_policy(VERSION). Now I'm forced to set this policy to OLD in order to not have a million warnings spam my team. if(POLICY CMP0043) cmake_policy(SET CMP0043 OLD) endif() you might wrap that into a macro, so you just hand in the list of (new) policies. 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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMP0043 warnings everywhere
On Monday, April 28, 2014 13:39:09 Brad King wrote: On 04/28/2014 01:26 PM, James Bigler wrote: I thought the purpose of policies was to keep some backward compatibility feature, but allow users to select the new behavior. The purpose is to change CMake interfaces or behavior while still building existing project releases that have not been updated by their developers to understand the new behavior: http://www.cmake.org/Wiki/CMake/Policies Now I'm forced to set this policy to OLD in order to not have a million warnings spam my team. Or, you could fix your project to not use the behavior deprecated by the policy. Other reasons are e.g. avoiding to annoy your developer team by warnings which don't matter (the build has been working, so there's no need to change it). Or, correct me if I'm wrong, isn't it possible that by fixing a warning the project then requires the cmake version which added the warning ? Which would mean fixing the warning would break the build with the (old) required cmake version ? 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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMP0043 warnings everywhere
On 04/29/2014 04:25 PM, Alexander Neundorf wrote: Or, you could fix your project to not use the behavior deprecated by the policy. Other reasons are e.g. avoiding to annoy your developer team by warnings which don't matter (the build has been working, so there's no need to change it). Yes, there is a need to change it. CMake deprecated an interface. The project should stop using it and use the replacement interface instead. The CMP0043 documentation explains how and gives examples. Or, correct me if I'm wrong, isn't it possible that by fixing a warning the project then requires the cmake version which added the warning ? Which would mean fixing the warning would break the build with the (old) required cmake version ? Almost all policies that deprecate old interfaces are added only after an overlap period with versions of CMake that have the new interfaces but do not warn about use of the old. This allows projects to use the new interfaces to avoid the warning while still working with CMake versions older than the one that introduced the policy. In this case the project need only require CMake 2.8.10 (which has been out for 18 months) and use generator expressions in the non-config COMPILE_DEFINITIONS. -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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMP0043 warnings everywhere
On Tue, Apr 29, 2014 at 22:59:50 +0200, Alexander Neundorf wrote: I was talking in general about these warnings. Typically some project has a working build system (...otherwise it wouldn't build), and after updating cmake, warnings appear. Since the build is working, there is no immediate need (for the project) to change anything in the buildsystem. The project will have an urgent need to change it once the old behaviour is not supported anymore. CMake would like to drop old interfaces eventually (see 3.0 dropping pre-2.6 behaviors) and if anyone tries to build it on a distro 3 years from now, not having to dig out CMake 3.0 from the dustbin while CMake 3.10 (or 4.x) is current would be nice. At least CMake is warning on behavior changes, preserving previous behavior as an option (provided you don't just straight from 2.4.0 to 3.0), and providing examples of how to update things versus autotools where Fedora ships old versions due to projects never updating. Actually, should 3.0 warn about cmake_minimum_required(VERSION 2.4.0)? --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMP0043 warnings everywhere
On Tue, Apr 29, 2014 at 22:31:27 -0400, Ben Boeckel wrote: Actually, should 3.0 warn about cmake_minimum_required(VERSION 2.4.0)? Silly me; 2.4.0 behavior is dropped and 2.2 does indeed warn. :) --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
