Re: Trigger missing dependencies by changing order of execution?

[Mike Shal]

On Thu, Mar 1, 2012 at 12:29 PM, Tim Landscheidt <address@hidden> wrote:
> 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.

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