|
Home > Archive > Unix Programming > January 2004 > make (possible FAQ)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
make (possible FAQ)
|
|
| Ian Zimmerman 2004-01-24, 5:34 am |
|
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.
| |
| Maurizio Loreti 2004-01-24, 8:34 pm |
| 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 http://www.pd.infn.it/~loreti/mlo.html
Dept. of Physics, Univ. of Padova, Italy ROT13: ybergv@cq.vasa.vg
| |
| Ian Zimmerman 2004-01-25, 5:36 am |
|
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.
| |
| mike burrell 2004-01-25, 5:36 am |
| 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 GNU
> 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
| |
| Ross Smith 2004-01-25, 5:36 am |
| 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
| |
| Ian Zimmerman 2004-01-25, 6:26 am |
|
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.
| |
| Maurizio Loreti 2004-01-25, 6:33 pm |
| 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 http://www.pd.infn.it/~loreti/mlo.html
Dept. of Physics, Univ. of Padova, Italy ROT13: ybergv@cq.vasa.vg
| |
| Barry Margolin 2004-01-25, 7:34 pm |
| 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 ***
| |
| Maurizio Loreti 2004-01-25, 11:33 pm |
| 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 http://www.pd.infn.it/~loreti/mlo.html
Dept. of Physics, Univ. of Padova, Italy ROT13: ybergv@cq.vasa.vg
| |
| mike burrell 2004-01-26, 5:35 am |
| 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
| |
| Ian Zimmerman 2004-01-26, 11:34 am |
|
Barry> I don't think that's how make works. It makes a plan at the
Barry> beginning.
Maurizio> No, it doesn't; but this may depend from the implementation. Look:
Maurizio> MLO@mlinux 26 $ cat Makefile
Maurizio> foo bar: quux
Maurizio> @echo executing
Maurizio> @touch foo bar
Maurizio> MLO@mlinux 27 $ rm -f foo bar && touch quux
Maurizio> MLO@mlinux 28 $ make foo bar
Maurizio> executing
Maurizio> make: `bar' is up to date.
Maurizio> MLO@mlinux 29 $ make --version
Maurizio> GNU Make 3.80
Maurizio> Copyright (C) 2002 Free Software Foundation, Inc.
Maurizio> This is free software; see the source for copying conditions.
Maurizio> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
Maurizio> PARTICULAR PURPOSE.
I think this is what I meant by the part about GNU make trying to
optimize but not documenting it. One case when the behavior changes (if
I remember right) is when the commands contain any macro reference.
I think classic Unix make works exactly the way Barry wrote.
--
Nothing can be explained to a stone.
Or to a stoned person, either.
|
|
|
|
|