From 0f1b09498acd36a7e80f34c28e400c7026b61a84 Mon Sep 17 00:00:00 2001 From: Karen Arutyunov Date: Sat, 24 Sep 2016 01:05:31 +0300 Subject: Add feature: Support for Compilation Database --- build2/compilation-database | 147 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 147 insertions(+) create mode 100644 build2/compilation-database (limited to 'build2/compilation-database') diff --git a/build2/compilation-database b/build2/compilation-database new file mode 100644 index 0000000..1a9705a --- /dev/null +++ b/build2/compilation-database @@ -0,0 +1,147 @@ +- Support for Compilation Database [feature] + +Number of CLang-based C/C++ code analyzing tools (such as clang-check, +clang-format, clang-tidy) require compilation flags to be provided for the +source file being analized. The information can be provided in the form of +Compilation Database (http://clang.llvm.org/docs/JSONCompilationDatabase.html). + +The following (referenced by llvm.org) tools generate compile_commands.json +file: + +* CMake >= 2.8.5. Command 'cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON' generates + compile_commands.json among other files. + +* Build EAR tool (https://github.com/rizsotto/Bear) creates json during build + process by intercepting compiler exec*() calls. + +* Bunch of wrapper scripts (https://pypi.python.org/pypi/scan-build) apply + intercepting approach as well. Command 'intercept-build b clean update' being + run in build2 project directory produces compile_commands.json file. + +* The Ninja build system (https://ninja-build.org/manual.html) produce the file + running a dedicated operation (ninja -t compdb rule1 rule2 ...) against + specified list of rules (whatever it means). + + +So how we would like to support that database? Specifically the questions are: + +* Which moment it is get generated and updated (if ever should)? + +* Where the json file should be placed? + +* Which files it should reference? + +Seems there is not much sense to have any long-living database being updated +by consecutive build2 runs. The different source files with inconsistent +compilation flags can be present in such a database which makes it pretty much +useless (if not to say harmfull). So probably generating new database by an +explicit request is the right approach. + +Probably generating the file as a part of update operation but being explicitly +asked for that would be the most intuitive way. Especially in the light of +build2 ability to change compilation options on the fly based on command line +variables. Meanwhile the resulted file should not dependend on the fact if +files it references were indeed compiled. So running update on cleaned up and +up to date project directory should result in the same database file. [That btw +not true about all mentioned interception-based tools which doesn't tell in +their favor.] For a symmetry clean operation could remove the file if +requested. + +The location of the resulted database file can be specified as a part of that +explicit request. + +The resulted database file can reference source files that are prerequisites +of the targets being built. It probably make sense to reduce the set to source +files belonging to the projects of the targets. We could even try to narrow +down further based on the assumption that user most likelly expect only the +files in the current working directory (and below) to be present in the +database. While maybe having some "extra" files is not an issue (as not very +likelly somebody will read them through too often) so project-based filtering +is probably a good compromise. + +Implementation-wise we could invent configuration variable(s) +(config.cc.cdbase=) not inventing any new build2 option(s). It could be +convenient to add the variable to the project configuration so the json file +reflects the last update operation and get removed with a clean operation. If + is an existing directory then /compile_commands.json file path is +assumed. + +Should be possible to run like 'b config.cc.cdbase=. bpkg/ brep/' so +compile_commands.json common for both projects is created in the current +directory. + + +Example of generating/using compilation database file: + +$ mkdir hello +$ cd hello +$ cat > hello.cpp < CMakeLists.txt <