[cmake-developers] [CMake 0015577]: The 'project' command overwrites CMAKE_CONFIGURATION_TYPES.
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15577 == Reported By:Cedric Guerin Assigned To: == Project:CMake Issue ID: 15577 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-20 11:38 EDT Last Modified: 2015-05-20 11:38 EDT == Summary:The 'project' command overwrites CMAKE_CONFIGURATION_TYPES. Description: If you have cmake files in a hierarchy of directories like in the sample provided, and use additional project commands in subdirectories (in my case in order to generate additional Visual Studio Solutions with only a subset of all the libraries generated), the project command will change the value of CMAKE_CONFIGURATION_TYPES to what appears to be a merge of the initial value outside any project declaration and it's current value, and this value will even be stored in the cache, affecting completely unrelated directory subhierarchies. Steps to Reproduce: Simply run cmake on the provided sample. Additional Information: The output of the provided sample in a fresh build directory is: CMAKE_CONFIGURATION_TYPES at start is : CMAKE_CONFIGURATION_TYPES before global project is : Debug;Release;Default CMAKE_CONFIGURATION_TYPES after global project is : Debug;Release;Extra CMAKE_CONFIGURATION_TYPES before libraries project is : Debug;Release;Extra CMAKE_CONFIGURATION_TYPES after libraries project is : Debug;Release;Default;Extra CMAKE_CONFIGURATION_TYPES for runtimes is : Debug;Release;Default;Extra While the expected output whould be for CMAKE_CONFIGURATION_TYPES to remain at Debug;Release;Extra once set. Note that you can remove the assigment to CMAKE_CONFIGURATION_TYPES outside any project, it's only there to help identify what occurs. Without it, cmake considers that the value outside of any project is the one stored in CMakeCache.txt (or the 4 default configurations if there is no CMakeCache.txt), but the overall behavior is the same. == Issue History Date ModifiedUsername FieldChange == 2015-05-20 11:38 Cedric Guerin New Issue 2015-05-20 11:38 Cedric Guerin File Added: Project.zip == -- 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 0015578]: Target property that sets Startup Project in MSVC
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15578 == Reported By:Davy Durham Assigned To: == Project:CMake Issue ID: 15578 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-05-20 13:10 EDT Last Modified: 2015-05-20 13:10 EDT == Summary:Target property that sets Startup Project in MSVC Description: A means of setting the (default) startup project for MS Visual Studio projects would be great. This is a rehash of mantis2919. In needing the same functionality, the consensus out there is to use https://github.com/michaKFromParis/slnStartupProject after generating the msvc solution with cmake. It is true that the startup project preference is stored in the .suo file and that cmake doesn't generate that, but that's *after* the solution has been opened for the first time. .suo files are not normally stored in source control because they change so much. MSVC apparently sets the first project defined in the .sln as the startup project when it is first opened (before any .suo file exists). And this is what this slnStartupProject application actually alters about the .sln file its given. Would it be possible to add a command, or target property for making sure some specific target is defined first in the .sln file? This would really be helpful. I can do more research if required. == Issue History Date ModifiedUsername FieldChange == 2015-05-20 13:10 Davy DurhamNew 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
Re: [cmake-developers] Regarding the 'run-include-what-you-use' topic
On 5/20/2015 8:48 AM, Brad King wrote: It also would be great to have more than one static analyzer enabled at a time. Like IWYU and clang-tidy and KWStyle and ... We also have support for asan, tsan: http://www.kitware.com/blog/home/post/762 We can also use scan-build (ccc-analyzer and c++-analyzer). https://open.cdash.org/viewNotes.php?buildid=3821481 I looked quickly at the clang-tidy docs and it looks interesting. I see it is setup to use the compile_commands.json file. Originally we looked at running iwyu using that file. However, it became quickly evident that this would be a pain to do. By using it as pre-compile command we can capture its output as compiler warnings and report them on the dashboard. In addition, it can be run in parallel by the build tool (make or ninja). I will take a look at clang-tidy as it might fit into the iwyu setup we created in a similar way. -Bill -- 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] Regarding the 'run-include-what-you-use' topic
On Wed, May 20, 2015 at 7:34 PM, Bill Hoffman bill.hoff...@kitware.com wrote: I looked quickly at the clang-tidy docs and it looks interesting. I see it is setup to use the compile_commands.json file. Originally we looked at running iwyu using that file. However, it became quickly evident that this would be a pain to do. I can confirm that it is a pain for clang-tidy too. By using it as pre-compile command we can capture its output as compiler warnings and report them on the dashboard. In addition, it can be run in parallel by the build tool (make or ninja). I will take a look at clang-tidy as it might fit into the iwyu setup we created in a similar way. Thanks, I am pretty sure it does. -- 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
