Working with jumbo/unity builds in C/C++
austinmorlan.com
Working with jumbo/unity builds in C/C++
1–10 of 45 posts
Re: Working with jumbo/unity builds in C/C++
#2This is easily the best overview of unity builds in C/C++ that I've seen. I'll definitely save and reference it in the future.
Re: Working with jumbo/unity builds in C/C++
#3Unfortunately this isn't consistent with how these terms are typically used. This article only explains the simple case where your program is small enough that you can compile all source files at once. That's not realistic or practical for much larger projects.
Both WebKit and Chromium support unity/jumbo builds. They combine around 20 source files at a time into a single compilation unit, which provides a reasonable tradeoff - making the full build noticeably faster without overflowing RAM and without making the cost of recompiling after a single change too large. You also get lots of parallelism.
Making a unity / jumbo build work for a project with 10,000+ files and millions of lines of code is not simple at all.
Re: Working with jumbo/unity builds in C/C++
#4Sqlite calls this an "amalgamation" build
Details here: https://sqlite.org/amalgamation.html
It's also touted as an easy way to embed sqlite.
Re: Working with jumbo/unity builds in C/C++
#5This is easily the best overview of unity builds in C/C++ that I've seen. I'll definitely save and reference it in the future.
I agree, I'm glad I read the article. Seeing the title jumbo/unity builds thinking this was not for me, but I'm doing some small C++ stuff, so I might try it out.
Re: Working with jumbo/unity builds in C/C++
#6Unfortunately this isn't consistent with how these terms are typically used. This article only explains the simple case where your program is small enough that you can compile all source files at once. That's not realistic or practical for much larger projects. Both WebKit and Chromium support unity/jumbo builds. They combine around 20 source files at a time into a single compilation unit, which provides a reasonable…
Making a unity / jumbo build work for a project with 10,000+ files and millions of lines of code is not simple at all.
Re: Working with jumbo/unity builds in C/C++
#7Unfortunately this isn't consistent with how these terms are typically used. This article only explains the simple case where your program is small enough that you can compile all source files at once. That's not realistic or practical for much larger projects. Both WebKit and Chromium support unity/jumbo builds. They combine around 20 source files at a time into a single compilation unit, which provides a reasonable…
Firefox uses “unified” builds, concatenating .cpp files only within each directory. Unified Firefox builds are about 2-5x faster on my Mac.
Non-unified builds are still built to make sure there are no unexpected side effects or accidental header file dependencies.
https://firefox-source-docs.mozilla.org/build/buildsystem/un...
Re: Working with jumbo/unity builds in C/C++
#8Unfortunately this isn't consistent with how these terms are typically used. This article only explains the simple case where your program is small enough that you can compile all source files at once. That's not realistic or practical for much larger projects. Both WebKit and Chromium support unity/jumbo builds. They combine around 20 source files at a time into a single compilation unit, which provides a reasonable…
> Chromium support unity/jumbo builds
used to https://groups.google.com/a/chromium.org/g/chromium-dev/c/DP...
Re: Working with jumbo/unity builds in C/C++
#9IMO separation of interface and implementation is one of the "good" things about C/C++ (I used to be confused about it when starting out), it gives you a good overview of a piece of code and how it is supposed to be used. In other languages with no such "feature", you'll have to scroll hundreds of lines of implementation details you don't care about to understand the interface. You say this as a possible solution:
> You can still use header files if you want to, they’re just no longer strictly necessary. You’re free to put struct definitions and function prototypes into a header file if you’d like.
But is it really? not enforcing header files across the codebase means that you'll definitely end up with some inconsistency sooner or later that will be hard to deal with.
> The order that you include the source files in all.c matters. In the above example, bar.c had to be included before foo.c because foo.c used a struct and function that was defined in bar.c.
This is just additional overhead that you don't need while implementing something new.
And in general, this goes against how normally C/C++ codebases are structured, I'm sure I'll be hella confused about a file called `all.c`.
Re: Working with jumbo/unity builds in C/C++
#10One issue that can happen that the article didn't mention is running out of AST node identifiers in Clang.
Clang uses a 32-bit number to identify AST nodes. If a single translation unit is large enough, it can overflow this and you can get some very weird compilation errors.