The original Steem source had an "odd" structure that has been "rectified" in Steem SSE. In Steem 3.2, most cpp files were included in big compilation units:
#include "cpu.cpp" #include "mfp.cpp" ...
I thought it was ugly. In Steem 4.0, all cpp files were compilation units. It was "proper" C++, yet builds had become very slow.
The price of performance, right? Well, think again! When the code is divided into so many units, the compiler can only optimise each of those units individually, not through the units. That's why link-time code generation was introduced in compilers. This is slow too.
The original Steem source was actually using the Single Compilation Unit technique, or amalgamation, which allows fast compilation and good optimisation, because the compiler sees everything it needs to. Of course, I was totally unaware of this (and nobody told me either).
An inconvenience of the Single Compilation Unit technique is that the scope of your variables and defines is larger. You can undef a macro, but your global variables and functions cannot be hidden. No big deal for a project like Steem.
Frustrated by the slow builds, I finally created alternative scripts that are more like the Steem 3.2 source. A unit for the emu, a unit for the gui, a unit for the optional debugger.
For the moment, those quick scripts are used for the betas, while the slow scripts are used for the releases. It's hard to see a performance difference between the builds.
So, again a lot of work for (almost) nothing, but no regret as it is all for fun!