implement features

[rizsotto]

Hey Guillaume, nice tool you've wrote. I was wondering that what's your opinion to implement these compilation database manipulations?

• convert all file path to relative from absolute
• convert all file path to absolute from relative

(Paths can be in directory and file, but also in the command arguments too. Like -I/path/to/include or -o /path/to/output.)

• filter out duplicate entries.
• filter compilation commands arguments.

(Duplicates could be when the directory and file, but the command has minor irrelevant differences like -MD or -static which are either preprocessing or linking flags. That's where the flag filtering could help.)

• exclude files with pattern

(Some project contains dependency code, which they might not want to run the tooling against.)

[Sarcasm]

Converting file paths relative <-> absolute, why not, but I'm curious, what use case do you have in mind? I remember a bug, in clang-tidy I believe, where I needed absolute paths in the compilation database or something like that. Found it: https://bugs.llvm.org/show_bug.cgi?id=22385

To filter duplicate entries, there is something already, but it's nothing smart, it just outputs one compile command per file:

compdb -p build/ list --unique

Filtering compilation commands arguments would be nice, but I'm wondering if/when I will get to it.

Excluding files with pattern, is something I'd like very much, for the reason you mentioned. I got this exact issue today.

[d]

@Sarcasm In general, custom tools written with libASTMatchers and libTooling have a problem dealing with files that are compiled from different directories. Specifically, when clang -I../../foo and clang -I../foo point to the same foo header search path, the LLVM filesystem abstraction gets really confused about foo.h (at foo/foo.h). This is a problem, when we capture the compilation database for an autoconf + recursive GNU Make project and run Clang-based tools over all files. We are forced to:

1. Either rewrite the compilation database to all align on the same base directory; or
2. run something like xargs -n1 <my tool> -p build.debug to work around this

[sim642]

I've just hit upon another use case for the absolute→relative paths conversion. In a CI environment, I generate the compilation database from cmake in one place and then want to use it to analyze the project inside a Docker container (with things mounted, but to a different path!). All the commands in the compilation database then refer to non-existent files, although relatively they could still be found.

In many cases it's not really feasible to ensure that all the containers manipulate the project at the exact same path, because different containers might require you to mount your stuff into different places.