Mike Shal <mar...@gmail.com> wrote: > [AO & tup]
> After adding 'a1' as an input to the b.out command, the update > completes. In my opinion, this is the correct behavior that should be > required of any build system. Namely, errors in the build description > are detected and reported when you make the mistake, not some > mysterious time down the road if the jobs happen to execute in a > particular order. This way you can fix them before committing broken > build files. Although your suggested patch of prerequisite reversing > or randomizing may help detect some of these errors, is it actually > guaranteed to find them? Or would you just have to run clean builds > for some N iterations and hope you found 'em all? Thanks for pointing out AO and demonstrating tup. The lat- ter certainly looks like what a build system /should/ look like. But in a cost/benefit ratio, there is also the cost to be taken into account :-). Converting a whole working build system to tup just to de- tect /possible/ errors is probably not suitable for most existing projects. So for detecting missing dependencies, I think AO looks more appropriate. However for tests to be run, they have to be easy to run. AFAICS, AO requires the developer to set up Tomcat. This is probably feasible if you have a CI server running anyway, but for a volunteer developer that threshold is far too high. So in an ideal world, I'd love to see AO integrated into GNU make so I can "make --audit" and get a nice report of any flaws. Until then :-), I don't need a guarantee to find all errors; but if there is a low-hanging fruit that in- creases the probability to find them, why not pick it? Tim _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make
