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. 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. > 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. > - 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. How do you propose to cover the new functionality in our test suite? 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. Thanks! -Brad _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers