Re: [cmake-developers] A policy for Policies
Brad King wrote: > We designed > policies to give projects smooth transitions from old to new behavior. > If we suddenly make an error occur in code that currently works > warning-free it will give policies and CMake a bad name. Ok. Actually I re-discovered this today in KDE4 http://quickgit.kde.org/?p=kdelibs.git&a=blob&h=a9aecfd3&hb=dde411c1&f=cmake%2Fmodules%2FFindKDE4Internal.cmake#l349 So, KDE4 as a platform breaks the cmake compatibility design for its downstreams. At least ECM, used by KDE Frameworks 5, doesn't do that. I still think they should be unconditional warnings. I also think we should make them REQUIRED_* eventually, but I expect you now never will. Thanks, Steve. -- 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
[cmake-developers] [ANNOUNCE] CMake 3.3.0-rc2 is now ready!
I am proud to announce the second CMake 3.3 release candidate.
Sources and binaries are available at:
http://www.cmake.org/download/
Documentation is available at:
http://www.cmake.org/cmake/help/v3.3
Release notes appear below and are also published at
http://www.cmake.org/cmake/help/v3.3/release/3.3.html
Some of the more significant features of CMake 3.3 are:
* The "if()" command learned a new "IN_LIST" operator that evaluates
to true if a given element is contained in a named list.
* The "add_dependencies()" command learned to allow dependencies to
be added to *interface libraries*. Dependencies added to an
interface library are followed transitively in its place since the
target itself does not build.
* The "find_library()", "find_path()", and "find_file()" commands
now search in installation prefixes derived from the "PATH"
environment variable.
* The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN"
target properties now affect compilation in sources of all target
types. See policy "CMP0063".
* A "_INCLUDE_WHAT_YOU_USE" target property and supporting
"CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell
the *Makefile Generators* and the "Ninja" generator to run "include-
what-you-use" along with the compiler for "C" and "CXX" languages.
Deprecated and Removed Features:
* The "ctest_build()" and "build_command()" commands no longer tell
"make" tools to ignore errors with the "-i" option. Previously this
was done for *Makefile Generators* but not others. See policy
"CMP0061".
* The "Visual Studio 7" generator (.NET 2002) is now deprecated and
will be removed in a future version of CMake.
* The "Visual Studio 6" generator is now deprecated and will be
removed in a future version of CMake.
* The "add_definitions()" command no longer causes a "DEFINITIONS"
directory property to be populated. See policy "CMP0059".
CMake 3.3 Release Notes
***
Changes made since CMake 3.2 include the following.
New Features
Generators
--
* The *Makefile Generators* now add ".DELETE_ON_ERROR" to the
makefiles that contain the actual build rules for files on disk.
This tells GNU make to remove rule outputs when their recipe
modifies an output but fails.
* The *Visual Studio Generators* learned to support ".xaml" source
files and automatically associate them with corresponding ".h" and
".cpp" sources.
* A new experimental "Green Hills MULTI" generator was added on
Windows. Green Hills MULTI is an IDE for embedded real-time
systems.
Commands
* The "add_dependencies()" command learned to allow dependencies to
be added to *interface libraries*. Dependencies added to an
interface library are followed transitively in its place since the
target itself does not build.
* The "execute_process()" command learned to support specifying the
same file for "OUTPUT_FILE" and "ERROR_FILE".
* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
"LIST_DIRECTORIES " option to specify whether the glob result
should include directories.
* The "find_library()", "find_path()", and "find_file()" commands
now search in installation prefixes derived from the "PATH"
environment variable.
* The "if()" command learned a new "IN_LIST" operator that evaluates
to true if a given element is contained in a named list.
* The "install(EXPORT)" and "export()" commands learned to export
targets that populate the "INTERFACE_SOURCES" target property.
* The "install(TARGETS)" command learned to support generator
expressions in the "DESTINATION" value.
Variables
-
* The version of some Fortran compilers is now detected and stored
in the "CMAKE_Fortran_COMPILER_VERSION" variable.
* The *Visual Studio Generators* learned a new
"CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" option to put the
"INSTALL" target in the default build of a solution (".sln") file.
Properties
--
* A "CROSSCOMPILING_EMULATOR" target property and supporting
"CMAKE_CROSSCOMPILING_EMULATOR" variable were introduced to allow
target platform binaries to run on the host during cross compiling.
* A "_INCLUDE_WHAT_YOU_USE" target property and supporting
"CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell
the *Makefile Generators* and the "Ninja" generator to run "include-
what-you-use" along with the compiler for "C" and "CXX" languages.
* The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN"
target properties now affect compilation in sources of all target
types. See policy "CMP0063".
* The "XCODE_ATTRIBUTE_" target property learned to
support generator expressions.
Modules
---
* The "CheckFortranCompilerFlag" module was introduced to check
"Fortran" compiler flags, much like the "CheckCCompilerFlag" module
already does for "C".
* The "ExternalData" module learned a new "ExternalData_NO_SYMLINKS"
option to disable use of symbolic links to populate the
Re: [cmake-developers] Issue #14894 fixed version
On 06/11/2015 04:18 AM, Petr Kmoch wrote: > Would it be possible to update the "Fixed in version" field in Mantis? Thanks. Done. -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] A policy for Policies
On 06/10/2015 03:52 PM, Domen Vrankar wrote: > I've read it in Mastering CMake and had to search for it today... On > page 42 it says that by default if cmake_minimu_required is missing it > sets policy version of 2.4. That's because version 2.6 was the first to introduce policies so using 2.4 leaves them all unset. Prior to that we had another mechanism called CMAKE_BACKWARDS_COMPATIBILITY which is now ignored when the version requested is 2.6 or higher. We cannot change the default value without possibly breaking existing scripts. -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator expressions for output directory/name (and install?)
On 06/10/2015 01:43 PM, Robert Goulet wrote:
> Ok I think I got something nicely integrated now.
Thanks. Here are some comments:
> + std::string GetDestination(const char* config=nullptr) const;
Please avoid C++11 constructs.
> +std::string cmInstallGenerator::GetDestination(const char* config) const
> +{
> + std::string configName = config ? config : ConfigurationName;
This should be able to use "std::string const&" as the argument type
instead. Just have the call sites pass ConfigurationName themselves
or create an argument-less overload that passes it for them.
Also please look at updating the test suite to cover this. The
Tests/ExportImport test has Export and Import sub-projects that
test installation of all kinds of targets. That may be a good
place to add tests for DESTINATION.
Thanks,
-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/mailman/listinfo/cmake-developers
Re: [cmake-developers] A policy for Policies
On 06/10/2015 05:41 PM, Stephen Kelly wrote: >> The presence of the warning from step (1) will mean projects should have >> long ported away from encountering the error. > > I think the same is true of the existing design of policies. The WARN > behavior of <= CMP0011 for the last six years is enough and we can error on > them. As you keep pointing out people *have* been setting policies to OLD like feature toggles. We cannot suddenly break them without warnings. The very plan that we've agreed on to use in the future acknowledges this. It will take a few releases to apply retroactively. I understand that you're doing a bunch of refactoring and supporting some of the policy OLD behaviors makes it harder, but we have to live with what has been done up to this point and deal with it. We designed policies to give projects smooth transitions from old to new behavior. If we suddenly make an error occur in code that currently works warning-free it will give policies and CMake a bad name. >> Projects that have been maintained but set policies to OLD will also be >> affected. Such projects need to be able to see warnings for a few >> releases first. > > What scenarios get the new CMake version into the hands of users who can do > anything about them? The projects that are maintained but set policies to OLD will see the new warnings and their maintainers will fix them. Our own test suite sits in this category as demonstrated by the fixes needed with your topic to get rid of errors caused by dropping support for OLD behavior. > They are warnings. By default. The warnings say "policy not set at all" and can be turned off and forgotten about for years by setting to OLD. We need to show them the new "policy not set to NEW" warnings that cannot be turned off except by fixing the code. -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/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015610]: ctest_update can fail without returning -1 as RETURN_VALUE
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15610 == Reported By:trsystran Assigned To: == Project:CMake Issue ID: 15610 Category: CTest Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-11 06:10 EDT Last Modified: 2015-06-11 06:10 EDT == Summary:ctest_update can fail without returning -1 as RETURN_VALUE Description: A ctest_update running git fetch failed: Update command failed: "git" "fetch" >From the LastUpdate*.log: fetch-err> fatal: Unable to create 'E:/repo/.git/refs/remotes/origin/master.lock': File exists. But in the CTest script we check for error: ctest_update(RETURN_VALUE res) if(res LESS 0) # stop if update error ctest_submit(PARTS Notes Update) return() endif() According to the documentation (http://www.cmake.org/cmake/help/v3.2/command/ctest_update.html) ctest_update must return -1 in such case. It didn't. The issue is in Sources/CTest/cmCTestUpdateHandler.cxx:292: "return numUpdated;" numUpdated is always returned, even in case of update error: the bool "update" should be used to return -1 == Issue History Date ModifiedUsername FieldChange == 2015-06-11 06:10 trsystran New Issue == -- 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
[cmake-developers] Issue #14894 fixed version
Hi all, we've been hit by #14894 (http://public.kitware.com/Bug/view.php?id=14894) in our project when using CMake 3.0.2. According to Mantis, it's fixed in 3.0, but neither tag v3.0.0 nor v3.0.2 seem to contain the fix. v3.1.0 does contain it. Would it be possible to update the "Fixed in version" field in Mantis? Petr -- 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
