Hi Brad, On Wed, Jan 12, 2011 at 8:25 AM, Brad King <brad.k...@kitware.com> wrote: > Hi Manuel, > > I think the goals of your work are important. I like the general > idea. One sure way to give such tools the same view of the code > as the compiler is to ask the build system to provide the information. > > I'm a CMake developer but I also wrote gccxml. The latter is a > code analysis tool that simulates the preprocessing performed by > a target compiler to get the same view of the code. We use it to > convert C++ header files into a .xml representation of the interface > for easy loading by interpreted language wrapper generators. > > In order to run gccxml in real projects we need to write CMake code > that uses add_custom_command to create build-time rules. Passing > the include path and preprocessor definitions requires custom code > to add them to the command line, and there is no guarantee that they > stay in sync with what the real compiler gets. This is difficult > to maintain. > > One distinction between gccxml and tools like you propose is that > gccxml has to run during the build to help generate code for the > compiler rather than running after the build to analyze the code. > However, the difficulty with running it to match the compiler > demonstrates why build system awareness is helpful.
Exporting the information in a defined way into the script language would be an option, too. If we have the information for example as a readable property for source files, writing the code that exports the data in any format in the cmake file is trivial - on the other hand I'd really like to create some form of well-defined "standard" format that tools can rely on finding. One other idea that looks like it would help especially your case would be to add an extra target command called "cxx_tool" or something that serves the purpose of running tools that need the c++ command line. I'd be also happy to spend some cycles on helping to implement that for the makefile case, as we're planning on tools like "include-what-you-use" (http://llvm.org/devmtg/2010-11/Silverstein-IncludeWhatYouUse.pdf) that you might want to run during a build, too. > On 1/11/2011 5:10 PM, Manuel Klimek wrote: >> I thought about that, too. On the other hand, we might also want to >> make that information available from other generators where it makes >> sense - in my mind it is somewhat orthogonal to the generator: >> - for generators that are already very tightly IDE integrated (like >> VS) we probably don't need to output this information, as the IDE >> already exposes this information in well-defined ways that tool users >> for those IDEs would use >> - for generators that are not tightly coupled to the IDE or where the >> IDE doesn't make the build information easily accessible (like >> Eclipse), we actually want to enable developers to make the output >> "default" in their cmake build setup, so they can use command line >> tools or hand-made macros in their editor/IDE. > > CMake has 2 categories of main generators: IDE and Makefile. The > Xcode and VS generators are IDE, the rest are Makefile. Other > generators like KDevelop are actually Makefile generators plus > project files that just list source files but not build rules. > > The IDE generators (Xcode and VS) do not actually generate the > final compile lines. Therefore the proposed functionality is > possible only with Makefile generators. However, since there > is no toolchain not supported by Makefile generators that should > be sufficient. Thanks for explaining. >> No, I'm not planning to output the link commands - this is purely for >> code understanding, not rebuilding the code - while thinking about how >> to enable fast rebuilds by adding this information might have some >> valid use case, it is currently completely out of scope as far as I'm >> concerned. > > My understanding is that clang is based on llvm which is a set of > modular components for all parts of the toolchain. It is conceivable > that tools in the future may be interested in the link line to do > whole-program analysis. However, I think starting off with just the > compile information is sufficient. Yes, I agree that it is very conceivable that we'll want that in the future - one reason I propose a JSON format is that it is both easy to parse and easy to extend. >> - you use your normal cmake+(your build system) workflow for building >> - you use tools that run over source files and use the little c++ >> compile database to be able to understand the c++ code correctly >> >> As a user, I want to be able to do both without having to run cmake in >> between. This might well be hidden behind a cmake configuration option >> if you think it affects the standard generation too much. > > I need to review your patch in more detail before commenting on its > effects on standard generation. If it is just a matter of writing > one extra file per logical target (created by add_executable, > add_library, or add_custom_target), then it shouldn't be too bad. It is actually a matter of writing one extra file globally - we have experimented with doing one-file-per-target stuff, but this requires knowledge about the build system's directory structure on the tool side. > How do you propose to cover the new functionality in our test suite? I didn't look into that yet :) Before spending more cycles on making this "production-ready" I wanted to get some agreement on the direction we want to take. > Currently your patch is one big change, but it looks like it factors > some existing code out into smaller pieces. Do you mind splitting > it into multiple Git commits in a topic branch? Ideally the first > commit(s) would just do the refactoring without changing behavior > and the later commit(s) would add the new functionality. This level > of granularity in the commits will make your change easier to review. Sure, will do. Cheers, /Manuel _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
