Standalone version of refresh.template.py

[AlexK-BD]

We've developed a standalone version of refresh.template.py, as that fits better with our workflow than invocation as a bazel template. There are some other changes, as well; some are specific to our monorepo deployment.

It doesn't seem like it, as a whole, would make for a meaningful contribution back to the project, however, some changes in it (I added some things to support our CUDA build) may be.

If possible, can you clarify what your license terms mean for this sort of derivative work?

[cpsauer]

Hey, Alex! Thanks for your interest and use of this tool--and for writing in. I'm glad to hear parts of it are serving you guys in modified form.

I'm always curious to learn how it's being used, especially when the stock version didn't cut it. Anything more I can learn from your use case, generalizable or not? [Sounds like this is a private monorepo (same as us, mostly)--I'm especially curious about the benefits that motivated the non template version. I'm also just curious what you guys are building more generally, if you can say!]

If you've got changes that'd be generally useful to others, I'd of course love it if you'd contribute back & upstream them with a PR. (And conversely, if they're specific to you guys or your private toolchain or something then no need, but we're certainly happy they work for you.)

^Re license, assuming my inferences are right: You're certainly free to customize things for your internal needs and use/share that modified version with your team! The callout about customizing it for your internal uses is meant to assuage any worries about the use case I think you're in. (lmk if that doesn't answer your question.)

Cheers, Chris

[AlexK-BD]

Thanks, I think that answers my question.

Our repo is large -- about 15k C++ source files not counting 3rdparty/externals -- so regenerating all the compile commands takes a long time. In addition, the complete index can bog down clangd. So people have wanted a more piecemeal/incremental approach to index subsets of the code.

So the standalone version I'm working on right now does two things:

1. The update is incremental. compile_commands.json is treated like a key-value store, and when you run refresh, it chooses what to update, keyed by file. This does mean some buildup of clutter over time.
2. The update is done from the command line, so that when someone realizes they don't have something in their database, or want a modified configuration, or whatever, all they have to do is run bazel run //:refresh_compile_commands -- --config=blah //my/subdirs/....

[cpsauer]

Thanks! Makes total sense, Alex.

That's actually a more common concern than you might think :) We're going to add an interface to support that shortly, in case you want to join in and deduplicate efforts.

The idea is to have a --file flag that incrementally updates the commands for a given file, with the idea that the editor would auto invoke it on file open. Would that also solve things for you?

Curiosity: Does the BD at the end of your username stand for a company? Always eager to hear what places are making use of the tool, just for my interest and feel-good about having helped.

-CS

[cpsauer]

Hey, Alex! Friendly bump

[cpsauer]

Alex, any thoughts on how the --file interface proposed in #99 would work for your use case?