compile_commands.json for an unusual file structure

Clang Frontend clangd
1

Hi.

We have our code structured in a somewhat unusual way. All *.cpp source files are included (#include …) in a number of *_package.cpp files. These *_package.cpp files are the ones configured in a Xcode project and in a Visual Studio project. The primary reason for this organization is to minimise the need to update Xcode and Visual Studio projects when adding new source files to the project (one just includes the new file in a suitable *_package.cpp file which is already a part of the project).

A consequence of this is that only the *_package.cpp files are visible in the compilation output. When we generate a compile_commands.json (using xcpretty since I’m on MacOS and using Xcode) this compilation database only contains entries for the *_package.cpp files. If I want to use for example Emacs and LSP this doesn’t work since a large part of the code base is not in the compilation database.

Would it be possible to add entries for each cpp source file that is included in the *_package.cpp files to the compile_commands.json (using a script). Would Clangd be able to parse this correctly? The idea is to copy the corresponding *_package.cpp entry in which the source file is included and alter the “file” part of the entry to refer to the source file instead, but leave the “command” part intact. This makes sense in a way since this is the way the source file is compiled even if it doesn’t show. Can Clangd work with this input?

Regards, Micke.

2

Hi Mikael,

I guess you should also fix “command” part in order to make clangd work with fine. So apart from fixing “file” you should replace *_package.cpp and *package.cpp.o entries in the “command” arguments with needed .cpp file paths. Just checked it, with improper “command” with clangd + emacs + lsp on macos I have no code completion.

3

Yep, unfortunately clangd doesn’t manage any of this for you now.

A fully-fledged version of this feature would be: if the compile command for a file compiles a different file, then we should complete as if we were compiling the outer file. This is hard due to our use of the preamble optimization and our assumptions the file is self contained. https://github.com/clangd/clangd/issues/45 - YCM folks have also requested this, it’s hard to fix.

On the other hand it should be easy to simply adjust the compile command to point to the right file. You won’t see e.g. #includes or #defines from the *_package.cpp wrapper, but this would still work in many cases. We should probably do that for now.

4

One can also try this tool
https://github.com/Sarcasm/compdb

It can generate compilation command entries for header files (by analysing includes I think), so probably it will do the trick in your case as well