On 01/11/2016 09:59 AM, Aleix Pol wrote: > I'm unsure of the feasibility of the project though. Getting any > changes in cmake takes forever (this initiative started almost 2 years > ago already and it hasn't had any impact yet)
This particular change will establish a much wider contract between CMake and IDEs than we have now, and it has never been clear what the best approach should be. That is why this change is taking so long. It was unfortunate that your (Aleix's) first iteration I reviewed and guided last year got so far and took you so much of your time before others came forward with criticisms of the approach, but I think in the long run we can do something better. > and we still need to proof the approach and make sure it has mechanisms > to provide retro-compatibility. At least to some extent. > > At the very least, I'd like to see cmake maintainers committing to the > initiative, to make sure I don't waste more of my time. Stephen's cmState refactoring has been a fantastic cleanup and improvement of the organization of CMake's implementation. It is a major step toward separating the configuration and generation steps and will be useful for many future directions of CMake. However, after needing to make fixes between 3.4.0 and 3.4.1 like these: cmState: Avoid accumulating policy stack storage for short-lived scopes https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f21dc4a8 cmState: Avoid accumulating snapshot storage for short-lived scopes https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f860ebb I'm concerned that the memory usage of a daemon implementing the proposed capabilities may be too large to be practical (at least without a major redesign of certain structures that tend to duplicate substrings, or some kind of out-of-core approach). The proposed daemon could help IDEs integrate with the CMake language without re-implementing it, but we may not need such heavy infrastructure for IDEs just to list targets and sources and allow users to edit them. The current need for it is due to the fact that the build specification is in an imperative language instead of a declarative format. I think a better approach forward is that discussed in this thread: CMake alternative language http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15374 Over there I propose moving the majority of the specification into a stateless format that IDEs could more easily load, edit, and save. While the daemon proposed here may have value, I think we should first resolve discussion of the approach proposed in the other thread. -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
