--- Begin Message ---
|
Subject: |
Re: bug#48188: Manual: Multiple outputs |
|
Date: |
Thu, 4 Nov 2021 19:21:39 -0600 |
Getting back to this automake doc report from May ...
> >
https://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html )
...
fh> > More importantly (at least to me), the final paragraph of the page
fh> > should really be first.
I agree. Moved.
ps> This example is wrong. You need the data.h target to have a recipe
Thanks. Deleted incorrect example.
Closing bug. --thanks, karl.
P.S. I wish there was a clean (non-gmake-only) solution for multiple
outputs that did actually meet all the desiderata. So far as I can
tell from reading that page, there isn't.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Manual: Multiple outputs |
|
Date: |
Mon, 03 May 2021 15:24:24 +0200 |
I had accidentally posted to bug-make@gnu.org first, but this
belongs to bug-automake@gnu.org.
Paul Smith wrote:
> On Mon, 2021-05-03 at 12:55 +0200, Frank Heckenbach wrote:
> > The manual (
> > https://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html
> > )
> > describes various ways to handle commands with multiple outputs.
>
> Just to remind, this is the mailing list for GNU make... the above
> manual is for automake which is a different project; we have no input
> into or control over their manual. You should be emailing their list.
Oops! I see that now. I had googled for "gnu make multiple outputs"
and got that page, and since it described make features without any
reference to automake, I didn't notice where I was. (And the last
paragraph links to the GNU make manual which is formatted exactly
the same, to add to the confusion.)
> > One intermediate solution that's said to work except with phony
> > dependencies doesn't actually seem to work:
> >
> > % cat Makefile
> > all: data.c data.h
> > data.c data.h: data.foo
> > touch data.c data.h
> > data.h: data.c
> >
> > % rm -f data.[ch]; touch data.foo; make -j
> > touch data.c data.h
> > touch data.c data.h
> >
> > It says "[...] therefore a parallel make will have to serialize the
> > builds of data.c and data.h, and will detect that the second is no
> > longer needed once the first is over." This doesn't seem to be so.
> >
> > Am I missing something?
>
> This example is wrong. You need the data.h target to have a recipe
> associated with it; it could be rewritten as:
>
> data.h: data.c ;
>
> (note the extra semicolon). Now it will work.
This gives me this error:
Makefile:4: warning: overriding recipe for target 'data.h'
Makefile:3: warning: ignoring old recipe for target 'data.h'
It goes away if I take out data.h in the first rule (not sure what
other consequences this might have).
This suggestion still stands (to the automake manual maintainers):
> > More importantly (at least to me), the final paragraph of the page
> > should really be first. After reading about increasingly more
> > complex solutions to handle various corner cases, I found it *much*
> > easier to just turn my rule into a pseudo-pattern rule a la:
> >
> > %ata.c %ata.h: %ata.foo
>
> Of course, this can't work if there's no common stem between the
> targets.
Yes. I'd prefer if "%" could match the empty string ...
(Anyway, I'd rather rename my files to create a common stem than go
through the contortions in the final example. ;)
> It also requires GNU make, which is a restriction that not
> all automake projects may be willing to accept.
Indeed, the manual page says so.
> In newer versions of GNU make there's a "grouped targets" feature which
> allows explicit rules to behave like implicit rules WRT multiple
> targets.
With emphasis on newer! 4.2.1 (my current default) accepts "&:",
but still runs the recipe twice. Only 4.3 seems to work correctly.
> But again, this is only helpful for automake projects which
> are willing to require a new-enough version of GNU make.
Or non-automake projects which require GNU make, such as mine.
--- End Message ---