Re: RFC: doc for `Handling Tools that Produce Many Outputs'

[Tim Van Holder]

> On Thu, Feb 05, 2004 at 10:49:07AM +1100, Robert Collins wrote:
> > On Thu, 2004-02-05 at 10:36, Eric Siegerman wrote:
> > 
> > > I believe this fails on the following corner case.  Suppose the
> > > date ordering is like this (with data.h being the oldest):
> > >   data.h   data.foo   data.c
> > > 
> > > data.h is out of date with respect to data.foo, so one wants to
> > > rebuild it, but I don't think that will happen:
> > 
> > 
> > Then data.c is not derived from data.foo. Or someone has 
> manually edited
> > it - either of which is incorrect for this scenario.
> 
> Or, after a build, the right version of data.h somehow got
> overwritten with an out-of-date version.  That's a user error
> too, of course.
> 
> I was well aware that this case "should never occur".  My point
> was that (as with any system or component) a Makefile that does
> the right thing when handed bad input is to be preferred over one
> that doesn't.  How much more important that is, then, for an
> officially recommended design pattern, which will (one hopes) be
> propagated into a great number of Makefiles!

The problem with bad input is that by definition there is no
"right thing" to do with it.
Make can choose to assume that the user intended for this situation
to occur and work around the older timestamp on data.h, or it can
substitute its own judgement and rerun foo (possible destroying user
changes).  Neither of these is really "right", but the first option
is arguably the least destructive.
Maybe the docs for the example should be expanded to make clear
that it assumes that the output files are never independently
modified.

I suppose using a stamp file might mitigate the problem:

data-made.stamp: data.foo
        foo $<

data.c data.h data.x: data-made.stamp
        touch $@

This ensures that the output files are only created if the stamp
file is missing or out of date.  And it is less likely that the
user will manually edit the stamp file, so this should generally do
the right thing - i.e. rerun foo if data.foo changes, and ignore
timestamp changes on the outputs.
But there are probably reasons not to use stamp files.

> On Thu, Feb 05, 2004 at 08:25:52AM +0100, Tim Van Holder wrote:
> > Wouldn't this help somewhat for a case like this:
> >    [example deleted]
> > 
> > It wouldn't do anything about the contents of the file
> 
> Why, then, is it to be preferred over an approach that does?

Because regardless of anything else, make shouldn't get hung up on
remaking data.h every time it runs.