Hi fellow Developers, I just uploaded a new version of the cmake-capabilities. I would appreciate some input:-)
This version still does parsing of the generator names. Stephen rightfully said that is not nice, which I fully agree with. But to avoid doing that I will need to create instances of generators and interact with those. Is that both safe and fast to do? I am a bit afraid that one generator or the other might end up doing some expensive checks on startup or maybe write files somewhere or do similar things I do not expect. Implemented changes include: Version reporting: * Rename "appendix" to "suffix" * Report "dirty" in the version section separately (information available via macro in cmVersionConfig.h) Code: * Do not use auto and range based for loops * Do not use std::unordered_map directly * Sprinkle this-> over the code Generators: * Hide KDevelop3 generator Best Regads, Tobias ________________________________ From: cmake-developers <cmake-developers-boun...@cmake.org> on behalf of Tobias Hunger <tobias.hun...@gmail.com> Sent: Thursday, July 7, 2016 3:51:52 PM To: Stephen Kelly Cc: CMake Developers Subject: Re: [cmake-developers] cmake -E capabilities Hello, On Tue, Jul 5, 2016 at 1:48 AM, Stephen Kelly <steve...@gmail.com>, me, Stephen Kelly wrote: >>> Such a feature would also work with cmake projects if the user chooses to >>> use the XCode generator on mac or VS generator on Windows (or if someday >>> we have a multi-config Ninja generator or so). >> >> How is a multi-config ninja generator better than just having to build >> directories next to each other, each with one configuration? You might >> save a bit of disk space (probably not a lot). Will you save a significant >> amount of processing time? >> >> The one benefit I can think of is switching between configurations will >> probably be a lot faster. But that is nothing that is done so often that >> it warrants optimizing for IMHO. > > What I have in mind is not optimization. As you say, if this is not needed > at this point for IDE integration, then we can drop the idea. I still do not get why this feature exists at all. What is the benefit of having it? Is it just because xcode supports it, so cmake should to? >> Either the clients do not care or they need to know which configurations >> those are going to be. > > This can be retrieved by reading the STRINGS property of the > CMAKE_BUILD_TYPE cache variable. Oh, that sounds interesting. I'll need to investigate this:-) Best Regards, Tobias -- Powered by www.kitware.com<http://www.kitware.com> Kitware Inc. - leading edge, high-quality software<http://www.kitware.com/> www.kitware.com Kitware's mission is to create state-of-the-art software products and services in visualization and data processing using advanced quality software methods and ... 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
-- 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
