Re: [cmake-developers] A policy for Policies
Brad King wrote: snip I recommend the following guidelines: 1) Policies need to result in errors in a short timeframe. They are not something to ignore for years, because allowing that makes them feature toggles. Alex won't be happy with this one obviously, but that's what I recommend. 2) Policies need to result in unconditional warnings in a short timeframe. Even -Wno-dev should have no effect on the warning when the warning is unconditional. If third parties are using -Wno-dev to silence output they need to know that will no longer work. It only works while there is an OLD state for the policy. I don't think more conditions with deprecation states is a good idea. Policy lifecycle should be simple to understand. It should be a loud notification to people who see it that they have an action item on their hands. Here's my recommendation for a way forward: CMake 3.4: * Policies = CMP0011 -- emit unconditional warnings for each policy (no OLD anymore - 6 years old) * Policies CMP0051 - CMP0054 -- emit unconditional warnings for each policy (no OLD anymore - 3 releases old) * Policies CMP0026, CMP0024 -- emit unconditional warning (CMP0026 warning will be in place for longer as many are affected, so start unconditional warning now). These are high priority because they make a better CMake implementation possible. CMake 3.5: * Policies CMP0001, CMP0003, CMP0004, CMP0006 - CMP0010 -- emit unconditional errors for each policy (the ancient ones except 'the KDE4 policies') * Policies CMP0055, CMP0056 -- emit unconditional warnings for each policy (no OLD anymore - 3 releases old) * Policies selection -- Select some other high-value policies to warn unconditionally on, eg CMP0031. CMake 3.6: * Policies CMP0051 - CMP0054 -- emit unconditional errors for each policy (unconditional warning for two releases already) * Policies CMP0058, CMP0063 -- emit unconditional warnings for each policy (no OLD anymore - 3 releases old) CMake 3.7: * Policies CMP, CMP0002, CMP0003, CMP0005, , CMP0011 -- Make 'the KDE4 policies' unconditional errors. Of course all of this needs to be malleable. Let's see what the response is to the warning behavior in 3.4 if you apply it. 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] [CMake 0015625]: Fix a typo in cmake-buildsystem(7) manual : Add missing INTERFACE_INCLUDE_DIRECTORIES
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15625 == Reported By:Erik Sjölund Assigned To: == Project:CMake Issue ID: 15625 Category: Documentation Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-20 03:00 EDT Last Modified: 2015-06-20 03:00 EDT == Summary:Fix a typo in cmake-buildsystem(7) manual : Add missing INTERFACE_INCLUDE_DIRECTORIES Description: The property name INTERFACE_INCLUDE_DIRECTORIES is missing from a set_property command in the manual http://www.cmake.org/cmake/help/v3.3/manual/cmake-buildsystem.7.html A patch was uploaded together with this bug report. == Issue History Date ModifiedUsername FieldChange == 2015-06-20 03:00 Erik Sjölund New Issue 2015-06-20 03:00 Erik Sjölund File Added: patch.txt == -- 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] Problems when creating config files and add_dependencies
Hello Brad, but the problem with this command is, that for multi configuration environments (e.g. Visual Studio), it requires $CONFIG in the filename which then creates 4 header files. One for each configuration. Maybe I didn't understand something, but after that I also need to call configure_file to resolve the rest of the CMake variables. After the 4 header files are generated, which one should I include in the unit test for example? Do you understand the problem? Thanks Roman Am 15.06.2015 um 15:10 schrieb Brad King brad.k...@kitware.com: On 06/12/2015 07:19 AM, Roman Wüger wrote: It would be great if generator expressions can be used with configure_file to avoid such overhead. Does anyone have an idea on how to solve that? See file(GENERATE). -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
