3 ms·
The article lists some specific limitations of the meta build systems but doesn't really get to the underlying, fundamental issue with the approach. Which leave
by boris 3y ago
The article lists some specific limitations of the meta build systems but doesn't really get to the underlying, fundamental issue with the approach. Which leaves the possibility of these specific limitations being addressed somehow and thus refuting the claim that meta build systems are fundamentally broken.
I think the fundamental issue boils down to aggregation. Normally, aggregation is a good thing, a variant of the divide and conquer technique which we were all taught in kindergarten you can never go wrong with. But in build systems aggregation leads to the loss of precision (rebuilding more than necessary) or accuracy (not rebuilding when necessary, rebuilding things in the wrong order), and usually both. This is the fundamental reason why "recursive make is considered harmful": we split one big graph that has the total, accurate view of all the dependencies into a number of aggregate sub-graphs. And the same happens with meta build systems where we do some part of the build (configuration, pre-build steps where we generate source code, etc) in the meta build system and the rest in the underlying build system, essentially splitting the graph into two.
P.S. And, yes, `build2` supports both dynamic prerequisites/dependencies[1] and dynamic targets[2].
[1] https://build2.org/release/0.15.0.xhtml#dyndep https://build2.org/release/0.15.0.xhtml#dyndep
[2] https://build2.org/release/0.16.0.xhtml#dyn-target https://build2.org/release/0.16.0.xhtml#dyn-target
- gavinhoward 3y agoI may not have said it as well as you did, but that is what I was trying to get across with the barrier analogy.