GNU bug report logs -
#48188
Manual: Multiple outputs
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48188 in the body.
You can then email your comments to 48188 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org
:
bug#48188
; Package
automake
.
(Mon, 03 May 2021 14:34:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
bug-automake <at> gnu.org, f.heckenbach <at> fh-soft.de
:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org
.
(Mon, 03 May 2021 14:34:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I had accidentally posted to bug-make <at> gnu.org first, but this
belongs to bug-automake <at> 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.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#48188
; Package
automake
.
(Sun, 09 May 2021 01:40:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 48188 <at> debbugs.gnu.org (full text, mbox):
fh> > 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
Yeah :(.
ps> 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.
fh> This gives me this error:
> Makefile:4: warning: overriding recipe for target 'data.h'
> Makefile:3: warning: ignoring old recipe for target 'data.h'
To be expected, since now data.h is a target in two separate rules with
recipes, and that is not allowed.
fh> It goes away if I take out data.h in the first rule (not sure
what other consequences this might have).
Well, it defeats the original purpose, which is to specify that data.foo
generates both data.c and data.h.
The only thing I can think of to do is remove that example. Maybe it
was never tried.
Paul (or anyone), do you see a better change to make?
fh> 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.
Ok. --thanks, karl.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#48188
; Package
automake
.
(Fri, 05 Nov 2021 01:22:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 48188 <at> debbugs.gnu.org (full text, mbox):
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.
Reply sent
to
Karl Berry <karl <at> freefriends.org>
:
You have taken responsibility.
(Fri, 05 Nov 2021 01:22:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
bug-automake <at> gnu.org, f.heckenbach <at> fh-soft.de
:
bug acknowledged by developer.
(Fri, 05 Nov 2021 01:22:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 03 Dec 2021 12:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 138 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.