On Wed, Feb 29, 2012 at 9:46 PM, Tim Landscheidt <t...@tim-landscheidt.de> wrote: > Olaf Hering <o...@aepfle.de> 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 _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make