> You don’t have to literally have only one translation unit.
Having 2 units per cpu core in your machine is a much better idea.
Working with jumbo/unity builds in C/C++
21–30 of 45 posts
Re: Working with jumbo/unity builds in C/C++
#22Unfortunately 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. True, but the number of such large projects is tiny (< 100?) compared to the tens of thousands of other smaller projects that might benefit. Good writeup.
I bet there are many more projects than 100. What makes you think the number is that low?
Re: Working with jumbo/unity builds in C/C++
#23> It's unfortunate that "Unity Build" is the prevailing term because it's impossible to do a search without getting a lot of results about the Unity game engine.
I ignored this article on the front page because of that. Only because it stayed on the front page for several hours did (and because I care about C++ build issues) did I eventually click on it.
Re: Working with jumbo/unity builds in C/C++
#24It's only faster if you are building from scratch, and even then it might not be faster. The resources required to build one huge compilation unit are also higher than compiling separately. If you support this type of build, it should not be the only option.
Re: Working with jumbo/unity builds in C/C++
#25Linked article describes manual approaches that create less reusable code.
Luckily there are unity build tools that do not require manual changes to code and work with normal .h/.cpp files automatically.
Re: Working with jumbo/unity builds in C/C++
#26Unreal Engine does unity builds quite well - it will, as part of a prebuild step: 1. Merge related cpp and h files together in groups into monolith files, usually in the order of 10-20 source files merged based on my observations - often entire modules will be grouped together. 2. Exclude any individual files from the monolith that have edits since the last change. It's a nice middle ground, you don't substantially s…
Unreal's unity builds get very annoying as soon as your teams exceeds a handful of developers. You often have code that has builds fine on a machine but doesn't on another developer - it completely depends on what order the UBT picks. This is even more annoying when you have some people on Windows, some on Linux, some on Macs, and they consistently get different results. The fact that most tools (Intellisense, all cl…
May be worth rethinking your module arrangements - unity builds have been stable for a while.
Re: Working with jumbo/unity builds in C/C++
#27> It's unfortunate that "Unity Build" is the prevailing term because it's impossible to do a search without getting a lot of results about the Unity game engine. I ignored this article on the front page because of that. Only because it stayed on the front page for several hours did (and because I care about C++ build issues) did I eventually click on it.
> and because I care about C++ build issues
Look no further, these builds will give you more than enough issues on any sizable project.
Re: Working with jumbo/unity builds in C/C++
#28Getting rid of header files for “jumbo builds” is, imho, a bad idea. “I don’t want to update two places” is, imho, insufficient reason. Thankfully this is optional. Combing many cpp files into a single translation unit is a good idea. More projects should do this. Infact I’d go so far as to say that most non-trivial, popularC++ projects on GitHub could and should probably be boiled down to a single translation unit.…
I don't undestand why there's still no solution for this in STL. Surely compilers like GCC could support a setup where STL instantiations are cached somewhere? If it was just one extra compile flag telling compiler to cache all template instantiations in some directory however it pleases, that would solve more than STL problems.
Re: Working with jumbo/unity builds in C/C++
#29Getting rid of header files for “jumbo builds” is, imho, a bad idea. “I don’t want to update two places” is, imho, insufficient reason. Thankfully this is optional. Combing many cpp files into a single translation unit is a good idea. More projects should do this. Infact I’d go so far as to say that most non-trivial, popularC++ projects on GitHub could and should probably be boiled down to a single translation unit.…
I don't undestand why there's still no solution for this in STL. Surely compilers like GCC could support a setup where STL instantiations are cached somewhere? If it was just one extra compile flag telling compiler to cache all template instantiations in some directory however it pleases, that would solve more than STL problems.
Modules, standardised in C++20, are the official solution both for the standard library and for other code but they are not universally well supported by all major compilers and build systems yet.
Transitioning existing code to use modules is also not entirely straightforward, though probably no more problematic than introducing unity builds.
Re: Working with jumbo/unity builds in C/C++
#30Earlier quoted context omitted.
I don't undestand why there's still no solution for this in STL. Surely compilers like GCC could support a setup where STL instantiations are cached somewhere? If it was just one extra compile flag telling compiler to cache all template instantiations in some directory however it pleases, that would solve more than STL problems.
Modules, standardised in C++20, are the official solution both for the standard library and for other code but they are not universally well supported by all major compilers and build systems yet. Transitioning existing code to use modules is also not entirely straightforward, though probably no more problematic than introducing unity builds.
> though probably no more problematic than introducing unity builds.
A "Unity build" really just means typing #include "foo.cpp" a few times. It's trivial.
Meanwhile, neither Clang nor GCC support standard library modules. They have only partial support for modules themselves. C++ module support is non-existent in almost all build systems. https://en.cppreference.com/w/cpp/compiler_support
The idea of C++ modules is great. It's badly needed. In practice I'm not sure if they're ever going to be genuinely functional and widespread. Which makes me sad. Toy projects don't count.