Brad King wrote: >> Alexander goes back to the generator approach we discussed a year ago >> and explicitly says he won't work on that, so nothing will happen >> there. > > The generate-json-description approach remains a valid alternative. > Aleix's work on it got pretty far before Stephen proposed the daemon > alternative.
In between I also made a generic-generated-JSON-file-based approach. > These problems are orthogonal, and your requirements certainly need > generation-time information regardless of how the build specification > itself is represented. Yes, this is the stuff that the protocol I put on github provides. > Therefore the discussion here should proceed > independent of where the alternative language thread goes. Yes. I count 3 orthogonal ways an IDE and cmake could 'interface': 1) Provide information about translation of sources into objects so that the IDE can understand those sources - eg includes and defines for c++ sources. 2) Provide semantic information about the CMake code, for example to introspect what is defined at what point in the file for debugging purposes, and for code completion purposes. 3) Provide a way for IDEs to *edit* the buildsystem. For example, if an IDE has an 'add class' dialog, or a 'extract class' refactoring action, they need to add a file to a target. The first two are what we have mostly discussed in previous threads that I linked in the OP. A generated JSON file in the buildsystem can provide (1), but can not provide the other interfaces. A well-designed declarative spec could make it easy for an IDE to do (3) but can not provide the other interfaces. A daemon can provide the first two in a high quality way and allows for more extensions in the future. As (3) is orthogonal, a daemon and a declarative spec for the sources covers all three. Even without the declarative spec, the daemon can tell the IDE exactly where to put the target_sources() command as an intermediate step (before the declarative spec is available), though that's 'ugly' so I didn't list it as something 'high quality' that the daemon could provide. > 2. CMake offers a daemon that IDEs can contact (e.g. via named pipes) > to ask for the information. The contract between CMake and IDEs is > a (to-be-designed) protocol (e.g. JSON snippets). Updating would > likely be handled internally by the daemon in response to changes > to the CMake input files between requests from the IDE. Right. If only some/deep/nested/CMakeLists.txt changes, and cmake knows that definitions do not escape via PARENT_SCOPE, and cmake knows that the targets defined in that file are not additionally modified elsewhere, it only has to re-evaluate the cmake code for that file and not for the entire buildsystem. > Stephen no longer has time to continue his work except to guide others. I can do development, but it would have to be as part of a collaborative effort and collaborative future maintenance. The latter part is the main reason I want to encourage fresh developers (and particularly IDE developers) into the cmake code to work on this, and to have some ownership on the code and design. > Given the above summaries my reaction is that the daemon approach is > more elegant and desirable in the long run. However, it will require > much more time and resources to implement. It is not clear how much > more, or if anyone has such time and resources to offer. Yes. I'm trying to generate interest in people who are capable of joining the effort, and interested in doing so. It is difficult :). > An intermediate solution could be to offer the daemon and protocol > to IDEs but to implement it internally on top of pre-generated JSON > files. That's even more effort, no? > The schema of the JSON files would remain a private contract > between "cmake" and "cmake-daemon". Then over time the implementation > of the daemon could be improved by computing things internally on > demand instead of updating and reading the JSON files, but the public- > facing protocol would not change. We just need to make sure that the > protocol is designed to allow such flexibility. OTOH this approach > requires designing both the daemon protocol and the JSON format. Yes. I don't understand the proposal. Why implement the protocol in terms of files generated by cmake, instead of implementing the protocol in terms of state in cmake (one less step)? > Note that the generated JSON approach is essentially what we've been > doing with the VS IDE since CMake started, just with a different format. Yes, but also without providing an interface for (2) and (3) above. > Many developers use the VS IDE to develop their CMake-built projects, > and they get IntelliSense for completion. It has worked well for years. > Perhaps the argument for the daemon approach puts too much focus on the > updating case while most developer time is simply spent editing existing > sources in their IDE. I don't understand this bit. Can you rephrase? 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