and yet I can mostly-deterministically build any of the main BSD kernels + base systems + UI + all applications and sometimes even package them into release media using 1-3 PMake invocations.. (without needing to embed a QT-based configuration GUI to do it).. don't think msft or goog need to build anything more complicated than that.. and i'd wager if they do some other process isn't working correctly..
(side note PMake is much better than GNUMake imho; syntax is more 'shelly' and there are build in looping constraints abilty to dynamically define targets based on variable contents (e.g. define a target 'T' who's target name will be the contents of the variable 'V'), unlike GNUmake's bizarre quasi-lispy syntax and functions)
> one-way dataflow constraints
definately not up on the theory; this sounds very similar to make target heirarchies (e.g target X is constrained by presence/absence of artifact Y)
I suspect you're right. And make (or whatever your platform default) is Good Enough™ for most people.
The heavy hitters (Microsoft, Google, ...) have code bases that are orders of magnitude larger than what most others have so their needs may just be different.
Anyway, one approach I find intriguing in terms of "availability" is what Jai uses: build "scripts" are just Jai programs evaluated at compile time. So if you are building a Jai program, it'll obviously be available.
A related aspect that somewhat still bugs me is that build systems really just seem to be special-purpose instances of one-way dataflow constraints[1], a feature that is tremendously useful not just for build systems, but also for UI/model interaction (MVC, one-way-dataflow, bindings), spreadsheets, etc.
Combining the two: shouldn't we have a language that supports dataflow constraints, and then use a part of the program that builds the rest of the program?
[1] https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-an...