Re: Trigger missing dependencies by changing order of execution?

[Tim Landscheidt]

Mike Shal <address@hidden> 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