Re: Trigger missing dependencies by changing order of execution?

[Mike Shal]

On Wed, Feb 29, 2012 at 9:46 PM, Tim Landscheidt <address@hidden> wrote:
> Olaf Hering <address@hidden> wrote:
>
>>> suppose I have a Makefile:
>
>>> | a.out:
>>> |     sleep 3
>>> |     touch a.out a1
>>> |
>>> | b.out:
>>> |     cat a1 > b.out
>>> |
>>> | c.out: a.out b.out
>>> |     cat a.out b.out > c.out
>
>>> "make c.out" will /usually/ succeed, as the commands for
>>> a.out are executed before the commands for b.out.  But "make
>>> b.out" will fail (in a clean directory), as will "make -j
>>> c.out".
>
>> How will make b.out fail? Because a1 is not present?
>> The example above has no rule to make a1.
>
> Maybe I should have written: "suppose I have a faulty
> Makefile" :-).

You won't get much help from make if you have a faulty Makefile (at
least, not for this kind of fault). You might want to look at AO
(http://audited-objects.sourceforge.net/). I don't know what the
standard way of using it as part of an iterative build process - I
assume you'd want some way of modifying your Makefile, and then using
AO to correct the "faults", as it were. I think the "Using AO to
Generate a New Makefile" section is what you'd want:
http://audited-objects.sourceforge.net/html/man/ao-tour.html - maybe
David can chime in if I'm way off base :)

I also tried your example in tup (http://gittup.org/tup/) which has
similar dependency detection to AO, but is a separate build system
from make. On the first execution I got an error because a1 was
written to but wasn't mentioned as an output:

$ cat Tupfile
: |> sleep 3; touch a.out a1 |> a.out
: |> cat a1 > b.out |> b.out
: a.out b.out |> cat a.out b.out > c.out |> c.out

$ tup upd
[ tup ] Executing Commands...
* 1) sleep 3; touch a.out a1
 *** tup errors ***
tup error: Unspecified output files - A command is writing to files
that you didn't specify in the Tupfile. You should add them so tup
knows what to expect.
 -- Unspecified output: a1 at dir 1

After adding an 'a1' output to that command, the next update results
in another error:

$ cat Tupfile
: |> sleep 3; touch a.out a1 |> a.out a1
: |> cat a1 > b.out |> b.out
: a.out b.out |> cat a.out b.out > c.out |> c.out

$ tup upd
[ tup ] Executing Commands...
 1) [3.026s] sleep 3; touch a.out a1
* 2) cat a1 > b.out
 *** tup errors ***
tup error: Missing input dependency - a file was read from, and was
not specified as an input link for the command. This is an issue
because the file was created from another command, and without the
input link the commands may execute out of order. You should add this
file as an input, since it is possible this could randomly break in
the future.
 - [12] a1

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?

-Mike