Dry run flag

[jackheizer]

I'm not sure if this makes sense to request, but I was wondering if it would be possible to add a --dry-run flag to bear.

Essentially in some contexts (such as the clangd indexer) I don't necessarily want to compile the resulting binary to get the compilation database as that can be time consuming. Rather I'm wondering if it's possible for bear to intercept the calls to the compiler but not actually run them in order to construct the compilation database.

Thanks!

[rizsotto]

Hi @jackheizer , that's a valid use case. It's in the backlog for a while. The upcoming 3.x version might support it. (That version will have compiler wrappers, which would be able to do this. But it's still many unknowns in the story.)

One challenge is that the wrapper still need to produce output. Otherwise the build system (eg.: make) will not continue. Then need to wrap the linker and other tools too, to deal with the fake output of the wrappers. And these still might fail, if one target in the build is executed (eg.: to generate source file). So the technique has limitations, and requires more efforts now.

[Petross404]

Compiledb is another tool to generate compilation database and has this ability with -n flag. One can take a look here.

[z-aki]

xcodebuild which is one use case for a tool like bear, supports -dry-run and it runs almost instantly for a build that otherwise takes 40 minutes.

[gianmarcoodorizzi]

Compiledb is another tool to generate compilation database and has this ability with -n flag. One can take a look here.

You're right. Too bad that that tools seems discontinued. Is there a workaround for this while we wait for an official implementation, @rizsotto?

[rizsotto]

@gianmarcoodorizzi the best workaround is to run the build. :)

[jbmaillet]

One challenge is that the wrapper still need to produce output. Otherwise the build system (eg.: make) will not continue.

Not really linked to the build time problem, but If that can be useful to anyone: with good old GNU make, there are 2 interesting options that I use:

--ignore-errors Ignore all errors in commands executed to remake files.

--keep-going Continue as much as possible after an error. While the target that failed, and those that depend on it, cannot be re-made, the other dependencies of these targets can be processed all the same.

With these, the compiler/linker do not need to succeed: they are called, whatever the result, and the call is caught by bear.

Ex: in my use cases, I'm only interested in a compilation database for the open source components. These more or less always build OK, so it does not hurt. It's always our proprietary code that is broken, and I don't need a complete compilation db for it for now (this may change in the future).

Of course this does not shorten the build time, or not by much, but at least I always get a usable output for my use case.