compiledb-generator and the generic Makefile proj.manager

[René J. V. Bertin]

Francis Herne wrote:


> A similar idea was mentioned on IRC a while ago, in that case it was using
> https://github.com/rizsotto/Bear .

IIUC compiledb is a more evolved alternative to Bear, in particular it has the 
advantage that it can get the information it needs without necessarily requiring 
a full build. That is, it can use `make -n`.

Of course that won't always work, a quick test on KDevelop's own source tree 
shows that moc-related targets are apparently (sometimes?) generated on the fly 
during a full make.
But at least it means that it's easier to keep the compile_commands db up-to-
date during incremental builds (make -n should succeed with minimal overhead 
after an initial full build).

> 
> The user did manage to get a "CMake" project working from their generated
> compile_commands.json after applying this [1] hacky patch (which I wrote the

Side-ways related: I've been forcing the use of the legacy cmake importer 
(because it used to be so much faster than the server-based version) by using a 
cmake wrapper that pretends to be an older cmake version when queried for its 
server capabilities. IIRC that doesn't require patching KDevelop.
This also has the advantage that a newly imported project gets configured 
according to the cmake settings you define through the wizard (AND gets a 
compile_commands db), something which apparently doesn't happen when you import 
a new project with the cmake server.

> initial version of), and it reportedly worked better than the 'Custom Make'
> plugin without needing hand-entered include paths etc.

Did s/he test with build.dir != source.dir by any chance? (You'd have to run 
configure outside of KDevelop, but then that is probably exactly what you'd do 
anyway...)

R.