Your bug report
#48188: Manual: Multiple outputs
which was filed against the automake package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 48...@debbugs.gnu.org.
--
48188: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=48188
GNU Bug Tracking System
Contact help-debb...@gnu.org with problems
--- Begin Message ---
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 ---
I had accidentally posted to bug-m...@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 ---
