+erikjv, who might have the perspective of yet-another-meta-build-system :)
On Thu, May 10, 2012 at 12:47 AM, Peter Collingbourne <[email protected]> wrote: > On Sun, May 06, 2012 at 03:20:59PM +0200, Stephen Kelly wrote: >> >> Hi, >> >> I've pushed a new branch to my clone for review to make the >> CMAKE_EXPORT_COMPILE_COMMANDS option work with the Ninja generator. >> >> https://gitorious.org/~steveire/cmake/steveires-cmake >> >> Thanks, >> >> Steve. > > Hi Steve, > > Thanks for working on this. > > I think the main problem with your changes is that they do not respect > the CMAKE_*_COMPILE_OBJECT variable, so the output will be wrong for > non-C++ compilers or compilers that do not take the conventional set > of command line parameters. > > Furthermore, there is no need to make paths within the build directory > absolute. Each command must be invoked from the home output directory > (i.e. the build "root" directory), so each command's "directory" > attribute should be set to that directory, rather than the start > output directory as in your patch. > > I am not sure if this is the best approach for building JSON files > from Ninja CMake builds. A few weeks ago I spoke with the folks at > Google who are working on Clang tooling, and I believe the current > thinking is that it may be best to teach Ninja to output JSON files > based on the provided build.ninja files. The advantage of this is > that it will work for any build system with a Ninja generator, and > there would be no need to add functionality to CMake which may impose > an additional maintenance burden and get out of sync with the > "real" build commands. As far as I recall we didn't come to a conclusion of what the "right" way to do it is, so let me try to summarize the thoughts we had first. With meta-build systems being common, there are basically 3 options for how to export build related information in a standardized format that is independent of the target build system: 1. Implement the output in every target build system Pro: - there might be implicit knowledge about the build that only the target system has - the format can be produced even when you don't have a meta build system Con: - some target build systems are hard to extend (make, VS, etc) - there are more target build systems then meta-build-systems 2. Implement the output in every meta build system Pro: - good meta build systems like cmake can abstract out common code for different target build systems, so there's less code to maintain overall - there are fewer places to implement the format Con: - not usable without meta build systems 3. A combination: Add support to some target build systems (like ninja) to support the format. Add support to meta build systems to output the format themselves for targets that don't support it, and add implicit targets to reproduce the information in the right spots for target build systems that support it. I think (3) is the optimal solution - target build systems can opt in to support the format, thus making use of their implicit knowledge about the build, while meta-build systems can ensure that no target system is left behind, using the common infrastructure to give basic support with little code. >From that perspective, I would argue that the proposed patch is a good thing (as it is not a lot of code and supports a real current pain (at least for me)), but we might want to rip it out once ninja supports compile command output itself. Thoughts? /Manuel -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
