Basically throughout 2017 June, Unity trunk had a problem where all C++ source files would be recompiled if you just did an Editor build followed by Standalone build, and were doing an Editor build again. Most of the build team was away (vacations/conferences), so it wasn't fixed ASAP :(
This is the fix: <url_removed>
I have spent close to three days tracking in down; in retrospect should have found it way sooner. Not quite sure why I didn’t :(
A combination of several PRs have caused this. Partially modularization work (split of unity assemblies into separate DLLs), partially CSharpTool build code refactor.
artifacts/generated/Modules.hwas being rebuilt (with identical location/contents) when building Standalone after just have built Editor; due to the way the target was gristed with active build target. And since it was just regenerated, then later on building editor would recompile everything again.- Various shared C# tools (e.g. bindings generator) were being rebuilt when switching architectures (e.g. editor default to 64 bit, standalone default to 32 bit) -- due to lost UseDepCache setting in some refactors. Rebuild of the tools caused all bindings files to be rebuilt as well. Which meant a ton of other things were rebuilt.
artifacts/generated/Modules.his setup as a dependency for all C++ source files in the world. Which means whenever someone adds a module, the whole world is rebuilt (kinda goes against the whole “modularization” idea, doesn’t it?).- The file is only actually used in scripting manager implementations, i.e. a handful of files out of thousands.
- What’s the underlying reason for making everything depend on it?
- Some modules report different .bindings files based on platform/architecture (SketchUpEditor). Which means that
switching between architectures will rebuild a lot of things, because artifacts/generated/bindings/DefaultEditorDll
etc is a shared location.
- I don’t quite know what DefaultEditorDll / DefaultEngineDll is though :)
- Jam’s depcache is not “just a cache”; misplaced or missing things in it can cause too much rebuilds (if UseDepCache or grists are misused), or wrong builds (if UseCommandLine is not specified properly).
- If different build targets generate/build files into shared locations (e.g.
artifacts/generated/Modules.h), be really careful about Jam’s grists!- Seems that there’s very few people who understand what grists are (I myself don’t), and many explicit usages of grists are copy-pasta from other seemingly similar code.
- Various Jam’s debug flags (-dX arguments) are not terribly useful; often they either don’t provide enough
information, or provide too much irrelevant information.
- During my whole debugging experience, they never quite said “this file, rebuilt due to Modules.h being more recent; repeat for all 1000 files”. Or maybe I missed that somehow, or I’m blind.
- Some of the “debug fate” (-df) output was flat out wrong; it was logging fate changes near a commented out code. Fixed that on github.
- When header files have cyclical dependencies (e.g.
LogAssert.h&EnumFlags.h), then Jam’s detailed fate/progress log will have a ton of spam thinking the whole cycle is “newer”, spamming the log. It does not affect the build as far as I can tell, but it does go in circles quite a lot in determining the fate. - For Bee, a detailed log mode “here’s why I’m rebuilding this target” that is non-ambiguous, non-noisy and actually correct is a must. Perhaps worth taking a look at improving Jam’s debug modes while we still use it.