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

[Eric Siegerman]

On Sat, Jan 31, 2004 at 11:28:29PM +0100, Alexandre Duret-Lutz wrote:
>    One of the output (here `data.c') is used as a witness of the run of
> `foo'. [...]

Hmm.  I understand what you're saying here, but "witness" seems
an odd choice of words to say it.  I can't think of a better one
offhand, though.  What's the French word you're trying to
translate?  Maybe that'll help me to think of something.  (My
French is pretty lousy, but I can usually muddle my way through a
dictionary entry -- especially one like
http://www.francophonie.hachette-livre.fr/, where each word in
the definition is a link to its own entry :-)


>    What we need is a rule that forces a rebuild when data.h is missing.
> 
>      data.c: data.foo
>              foo data.foo
>      data.h: data.c
>              @if test -f $@; then :; else \
>                rm -f data.c; \
>                $(MAKE) $(AM_MAKEFLAGS) data.c; \
>              fi
> 

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:
  - data.c is up to date with respect to data.foo, so the first
    rule doesn't fire
  - data.h is out of date with respect to data.c, so the second
    rule does fire, but its action doesn't do anything because
    data.h already exists

But removing the conditional from the second rule puts us back
into the same situation as the first, naive attempt:
    data.c data.h: data.foo
            foo data.foo

I'm tempted to suggest that any make program that does the
redundant "foo" execution (in a non-parallel build) is buggy, and
the problem is benign anyway.  If the naive approach doesn't
work, live with it or get a better "make".

As for parallel builds, how about this variation:
        data.c data.h: data.foo
                foo data.foo
        data.h: data.c

If you have a buggy (see above) make, you'll still get two
executions of "foo", but the second rule will force them to run
sequentially, which gets around any concurrency problems.  As a
bonus, if your make is *not* buggy, that serialization should
guarantee that the second "foo" is suppressed.

This scales to multiple outputs too, but it gets a bit ugly, since
one has to impose a serial ordering on all of them:
        data.c data.h data.x data.y: data.foo
                foo data.foo
        data.h: data.c
        data.x: data.h
        data.y: data.x

I haven't tested either of these approaches; just throwing them
out for consideration.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
        - Patrick Lenneau