I'm not too active on the forums but I've been lurking in the background following the series here and there, mostly referencing parts of interest and not following in a sequential matter.
Recently I came across the idea of a unity build and it blew my mind in a good way. I'm not really as interested by the compilation performance benefits (although those are nice), but the epiphany was the realisation that most model languages seem to conflate code organisation and dependency management.
Now as a *cough* web developer *cough* I'm pretty familiar with the idea of organising code into modules/namespaces and using some kind of import mechanism. Conceptually most modern languages end up building up a graph of code dependencies that can be difficult to reason about of often result in annoying issues like cyclic dependencies where there cycle is a few steps removed.
Conceptually it's much simpler (and in my mind simpler is generally better) to conceptually think of most of you application as a single file/compilation unit that is split among multiple files.
When researching unity builds I noticed that the general sentiment tends to be that they are good as some kind of "compilation performance hack", but not really as a way to structure programs. I've been looking through some open source game engines (gemrb, stratagus, etc) and unexpectly none of them use a structure like this.
How common is it to structure projects where is compilation unit is a unity build in practice? My feeling is that it is uncommon, and if so is there a good reason why one might not want to build their application this way?
I'm a Clojure developer by trade so I'm pretty unfamiliar C/C++ normals and common industry practices in general so I'd love to hear opinions from people who work with C/C++ on a regular basis.