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.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Frank Heckenbach <f.heckenbach <at> fh-soft.de>
To: bug-automake <at> gnu.org
Cc: bug-make <at> gnu.org, psmith <at> gnu.org
Subject: Re: Manual: Multiple outputs
Date: Mon, 03 May 2021 15:24:24 +0200

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.

Message #8 received at 48188 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: 48188 <at> debbugs.gnu.org, psmith <at> gnu.org
Subject: Re: bug#48188: Manual: Multiple outputs
Date: Sat, 8 May 2021 19:39:24 -0600

    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.

Message #11 received at 48188 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: 48188 <at> debbugs.gnu.org
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.