On Thu, Mar 1, 2012 at 12:29 PM, Tim Landscheidt <t...@tim-landscheidt.de> wrote: > 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.
Definitely, I understand there is some conversion pain. And, tup doesn't work in all cases. Though I think just because there are limitations in my particular implementation doesn't mean that the ideals it espouses are wrong :) > > 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? I think a 'make --audit' would definitely be a step in the right direction. That alone would probably have saved me many days of frustration when I have to use make. I would still have issues with the lack of scalability, so for me it would not be so useful. I do think direct auditing would be better than the indirect prerequisite re-ordering approach, though. I just imagine waiting for an hour long build to complete some N-factorial times, and at the end you still have no idea if it is actually safe. -Mike _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make