So, how does one handle, in plain make, the situation where multiple
outputs depend on the same input, and the same command updates both
outputs?

The GNU make manual says if both outputs are listed as targets of the
same rule, the command will be run twice, once for each target --- which
isn't what I want.  I remember the real situation was more complex with GNU
make, it tried to optimize this, but it was undocumented and impossible
to figure out.

Also, presumably the documented behavior is what other make implementations
do, and I'd like to stay compatible with them.

--
Nothing can be explained to a stone.
Or to a stoned person, either.

[ Post a follow-up to this message ]

Ian Zimmerman <bayard@newsguy.com> writes:
quote:

> So, how does one handle, in plain make, the situation where multiple
> outputs depend on the same input, and the same command updates both
> outputs?


target1 target2: input
command

--
Maurizio Loreti                         [url]http://www.pd.infn.it/~loreti/mlo.html[/ur
l]
Dept. of Physics, Univ. of Padova, Italy              ROT13: [email]ybergv@cq.vasa.vg[/emai
l]

[ Post a follow-up to this message ]

Ian> So, how does one handle, in plain make, the situation where
Ian> multiple outputs depend on the same input, and the same command
Ian> updates both outputs?

Maurizio> target1 target2: input command

Maybe you could read te whole post :-)

--
Nothing can be explained to a stone.
Or to a stoned person, either.

[ Post a follow-up to this message ]

In gnu.utils.help Ian Zimmerman <bayard@newsguy.com> wrote:
quote:

> So, how does one handle, in plain make, the situation where multiple
> outputs depend on the same input, and the same command updates both
> outputs?
>
> The GNU make manual says if both outputs are listed as targets of the
> same rule, the command will be run twice, once for each target --- which
> isn't what I want.  I remember the real situation was more complex with GN
U
> make, it tried to optimize this, but it was undocumented and impossible
> to figure out.


I would just make one output file depend on the other.  e.g., I recall doing
something like this once or twice:

y.tab.h:	y.tab.c
y.tab.c:	foo.y
yacc -d foo.y

Where yacc creates two output files for one input file.  It's perhaps not
the cleanest way of doing things....

--
/"\                                                 m i k e   b u r r e l l
\ /     ASCII RIBBON CAMPAIGN                                mikpos@shaw.ca
X        AGAINST HTML MAIL,
/ \      AND NEWS TOO, dammit

[ Post a follow-up to this message ]

Ian Zimmerman wrote:
quote:

>
> So, how does one handle, in plain make, the situation where multiple
> outputs depend on the same input, and the same command updates both
> outputs?
>
> The GNU make manual says if both outputs are listed as targets of the
> same rule, the command will be run twice, once for each target ---
> which isn't what I want.


Use an intermediate target that both targets depend on:

.PHONY: both

both:
command

target1 target2: both

--
Ross Smith ......... r-smith@ihug.co.nz ......... Auckland, New Zealand

"This world is like a burnt steak: small, tough, and the chips
are always stacked against you." -- Mike

[ Post a follow-up to this message ]

Ian> So, how does one handle, in plain make, the situation where
Ian> multiple outputs depend on the same input, and the same command
Ian> updates both outputs?
Ian>
Ian> The GNU make manual says if both outputs are listed as targets of
Ian> the same rule, the command will be run twice, once for each target
Ian> --- which isn't what I want.

Ross> Use an intermediate target that both targets depend on:

Ross> .PHONY: both

Ross> both: command

Ross> target1 target2: both

Thanks, this works and is what I ended up with.

--
Nothing can be explained to a stone.
Or to a stoned person, either.

[ Post a follow-up to this message ]

Ian Zimmerman <bayard@newsguy.com> writes:
quote:

> Maybe you could read te whole post :-)


I did.  If running "command" is triggered by inadequacy of target1,
but updates both target1 and target2, a second run of command is never
triggered being now target2 up-to-date..

Maybe you could try the suggested solutions :-)

--
Maurizio Loreti                         [url]http://www.pd.infn.it/~loreti/mlo.html[/ur
l]
Dept. of Physics, Univ. of Padova, Italy              ROT13: [email]ybergv@cq.vasa.vg[/emai
l]

[ Post a follow-up to this message ]

In article <rm7jzfp5z0.fsf@mlinux.pd.infn.it>,
Maurizio Loreti <mlo@foobar.it> wrote:
quote:

> Ian Zimmerman <bayard@newsguy.com> writes:
> 
>
> I did.  If running "command" is triggered by inadequacy of target1,
> but updates both target1 and target2, a second run of command is never
> triggered being now target2 up-to-date..


I don't think that's how make works.  It makes a plan at the beginning.
So if target1 and target2 are initially out of date, it will plan on
running the rules that update each of them.  If updating target1 also
updates target2, it won't revise its plan; it will still run the rule a
second time to update target2.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[ Post a follow-up to this message ]

Barry Margolin <barmar@alum.mit.edu> writes:
quote:

> I don't think that's how make works.  It makes a plan at the beginning.


No, it doesn't; but this may depend from the implementation.   Look:

MLO@mlinux 26 $ cat Makefile
foo bar: quux
@echo executing
@touch foo bar
MLO@mlinux 27 $ rm -f foo bar && touch quux
MLO@mlinux 28 $ make foo bar
executing
make: `bar' is up to date.
MLO@mlinux 29 $ make --version
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

--
Maurizio Loreti                         [url]http://www.pd.infn.it/~loreti/mlo.html[/ur
l]
Dept. of Physics, Univ. of Padova, Italy              ROT13: [email]ybergv@cq.vasa.vg[/emai
l]

[ Post a follow-up to this message ]

In gnu.utils.help Maurizio Loreti <mlo@foobar.it> wrote:
quote:

> Barry Margolin <barmar@alum.mit.edu> writes: 
>
> No, it doesn't; but this may depend from the implementation.   Look:


You're right.  It doesn't work so well for parallel builds though:

$ make -j 2 foo bar
executing
executing
$

--
/"\                                                 m i k e   b u r r e l l
\ /     ASCII RIBBON CAMPAIGN                                mikpos@shaw.ca
X        AGAINST HTML MAIL,
/ \      AND NEWS TOO, dammit

[ Post a follow-up to this message ]