Tip: Clion (maybe other IDEs) vs. Platformio and large builds

[robertlipe]

TL;DR: Consider disabling indexing in any IDE or other tooling (an fswatch rebuiling LSP would also qualify) on the .pio directory in your work tree.

This might impact like five people in the world and it's possible that three of them don't care, but in keeping with my mission of writing down life's hard lesson's, here's today's "Lipe Pro Tip". :-)

Since we can't run a presubmit test, those of us working on common code should probably be running a 'python3 tools/build_all.py' just to be responsible before submitting. This process (and this is PIO's stupidity...) does incredibly annoying things like fetching a full 41 copies of UrlEncode, IRRemote, Bounce2, FastLED, and several others, and then building them from there (ensuring that our build cache, even when fronted via ccache, is helpless) and then builds them. It's a painful process. Even a reasonably spritely laptop is simply not spritely when pushing around 57 GIGABYTES of schtuff in .pio. It takes over an hour on an M1 with 16GB of RAM.

If you use CLion (it's likely other IDEs are similar; I'm really not an IDE guy...) to build the project from the compile_commands.jsons and have left it running while doing a full build, the indexer will spend about four cores dutifully indexing all those .cc files that are magically appearing in .pio while you run.

Of course, you don't really want that indexed in the normal case at all and you'd rather have those four cores running python (python uses more CPU than gcc does while building. Good job, scons & platformio 😐) and actually moving the progress ball forward instead of indexing that 37'th copy of a file you don't care about anyway.

The solution (well, a solution; a "better" solution might be to build a real cmake build configurations for CLion and rejoice in faster build times, but as much as I dislike Platformio's build system, I'd rather eat a big, wiggly bug than maintain parallel build systems.) is to tell CLion that the .pio directory simply doesn't exist. Control click on the .pio directory and mark it as excluded. I've already done so here; that's why it's in burnt orange. I've highlighted the following directory so you can see where the option is.

This isn't without tradeoffs. One of the reasons I'm trying to make friends with an IDE is to help chase down where any given piece of code in this project REALLY is (It may not even be in our tree. It might be in ~/.espressif? ~/.platformio?) in case I have to debug it. If you're doing multiple, full builds (sucks to be you!) it might even be worth just quitting the IDE during large builds and letting it index everything in bulk when next restarted.

So there's no real question here. It's just another hard-learned lesson that I thought I'd share.

Trivia: After performing a complete and successful buildall, running it again, where in theory nothing is changed and nothing SHOULD have to be fetched or recompiled, is still painful.

That stupid dependency finder takes longer than just rebuilding many of our files. Similarly, even though we now cache objects by default, python/scons take longer to copy/link the cached copy in many cases than it would to simply recompile again. Not all files are that short, so overall it's a win.

$ time python3 tools/build_all.py
_ticking away the moments that make up a dull day..._
Builds completed successfully.
python3 tools/build_all.py  926.86s user 161.58s system 153% cpu 11:48.05 total

That's fifteen and a half minutes to generate...exactly nothing.