Hi Egor! This thread very much resembles my suggestion from two years ago, when I proposed there should be an intermediate representation of the CMake scripts so generators can be implemented against a stable IR as opposed to bare C++ constructs. (Google „CMake IR”)
My main motive too was to give CMake an alternative front-end beside the CMake scripts language. I am productive enough with it (not comfortable), but most people (even my students at university) have a very hard time mastering it. Most abandon CMake at the first possible moment and simply cook build.sh scripts for Linux while using Visual Studio click-click project generation together with MSBuild (now also available on Linux). IDE tooling will hopefully help in that regard. My first thought was PowerShell, but Python is equally applicable. Having an IR instead of C++ API to hook into is vastly simpler, hence my original proposal. The CMake server mode tackles a very similar issue, but that solves only part of this equation: external tools extracting information from CMakes internal machinery. It does not help in injecting information, or outright generate the entire process. If CMake were able to consume the same type of JSON it is able to dump as an output, such tooling were much easier to implement. Even though enabling the main executable to consume server mode json and execute it is less work than modularizing the entire code base, actually refactoring the code in such a way would have collateral benefits. It wouldn’t just facilitate the authoring of 3-rd party front-ends, but would also facilitate cooking up language services inside IDE-s. If the CMake script lexer-parser were available together with server mode, it would enable for much more precise IntelliSense capabilities in all IDEs. I still believe though that having a well defined set of schemas (may them represent a script AST or a declarative workflow (or both)) would benefit CMake in the long run. Feladó: Egor Pugin Elküldve: 2017. május 11., csütörtök 18:55 Címzett: Brad King Másolatot kap: CMake Developers Tárgy: Re: [cmake-developers] Splitting CMakeLib I see, thanks! I'll ping when something is ready, but do not expect much in the near future (2-4 months). On 11 May 2017 at 16:21, Brad King <brad.k...@kitware.com> wrote: > On 05/10/2017 10:56 AM, Egor Pugin wrote: >> I'd like to re-use some CMake internal components, but CMakeLib looks too >> fat. >> Is it possible to split it into several libraries? Are such changes >> welcome to contribute? > > Refactoring/organizing/cleanup changes like that would certainly be welcome. > >> Some rough plan: >> 1) Support library (if any stuff) >> 2) Core library (targets etc.) >> 3) Generators library >> 4) CMake syntax library (lexer, parser) >> 5) Commands implementation library (could be merged with 4) >> >> True cmake power is in its generators. It's always possible to rip off >> all other stuff, but in order to be tied with mainstream and >> contribute back, I'm asking this. > > Stephen Kelly had started work toward separating the code model from the > language. The code model should become an independent representation that > can be input to the generators but be produced independent of the language. > See cmState for example. He isn't working on it anymore but left a thread > some time ago on this list enumerating some future work that could be > picked up by others (I don't recall which thread though). > > -Brad > -- Egor Pugin -- 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
-- 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
