diff options
Diffstat (limited to 'build2/compilation-database')
| -rw-r--r-- | build2/compilation-database | 39 |
1 files changed, 27 insertions, 12 deletions
diff --git a/build2/compilation-database b/build2/compilation-database index c5a6dea..daa9170 100644 --- a/build2/compilation-database +++ b/build2/compilation-database @@ -9,6 +9,10 @@ Notes * Incremental analysis seems to be important (i.e., only re-analyse TUs that have chnaged). +* Differential analysis: see only new errors compared to some base report (a + way to live with false positives as well as gradually cleaning up existing + codebase). + Questions ========= @@ -53,20 +57,31 @@ 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 +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 [not sure about that: what about incremental re-analysis?]. [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. + +Are we going to provide some integration for actually running the tools? In +other words, one could have configured a build with static analysis tools +which are automatically invoked either after update (we have a notion of +post-operation which we can probably use here) or as a separate operation? +Having static analysis diagnostics as part of normal compilation diagnostics +definitely sounds appealing (thought apparently they can take significantly +longer than compilation plus there false positives). If we go this route the +question is then why do we even need the compilation database? Are these tools +somehow rely on the ability to see all the commands at once or is it just the +least invasive way to retrofit them into existing build systems? + +The location of the resulting database file can be specified as a part of that explicit request. -The resulted database file can reference source files that are prerequisites +The resulting 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 |