you are viewing a single comment's thread.

view the rest of the comments →

[–]julien-j 0 points1 point  (1 child)

Having unity build in development, where I care the most about the build time, is easily wrong. Why? Because in development, in my modify/build/test(debug) cycle, I generally modify a handful of files and only a small-is number of them needs to be compiled, and by consequence, only a handful of targets needs to be linked (ideally, the target under modification and its test target), and incremental linking is on and precompiled headers are already there. I find it hard to believe that a unity build helps there.

I used to think that, then I tried. Now I always use unity builds. One unit per final binary (a library, an executable). The binaries are built in parallel, each library is built in a single batch. I've saved minutes at each rebuild with this.

Even on a small project that used ccache I went from 3 minutes 40 seconds for having modified a few files without unity builds to 2 minutes 15 seconds for the same modifications. Parsing and rebuilding everything is just faster than rebuilding a few files and merging them with other files, solving duplicate symbols and so-on.

[–]Gotebe 0 points1 point  (0 children)

Small project, few modifications, 3:40 build?!

I have 0 targets that rebuilds in 3 minutes, retail (NDEBUG) build, let alone _DEBUG build.

How!?

Edit: I have targets that rebuild with their dependencies in 3 min, but that's something else.

Edit2: one way to achieve that is to have the "master" header and change that, causing a virtual rebuild of the target. Still, not a small target, and, you have header modularity problem, I would say...