help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Implement "grouped targets" in ordinary rules.


From: Paul Smith
Subject: Re: [PATCH] Implement "grouped targets" in ordinary rules.
Date: Wed, 13 Mar 2019 08:28:53 -0400
User-agent: Evolution 3.30.1-1build1

On Tue, 2019-03-12 at 20:50 -0700, Kaz Kylheku (gmake) wrote:
> This patch (against 4.2.1) adds the + (plus) syntax:
> 
>    + tgt1 tgt2 ... tgtn : pre1 pre2 ...
>          recipe

Hi Kaz; thanks very much for your interest in GNU make!  This is a
useful feature that many people have wanted.

You may find more info about this on the Savannah bug tracker:

https://savannah.gnu.org/bugs/index.php?8297

In the past when we've discussed this, we were considering using the
special symbol "&:" (one token, no spaces allowed) replacing the ":" to
denote a "grouped" rule like this.  I think that implementation would
be simpler to parse than the one you suggest.  There are a number of
places where adding a new special token to the parser can cause
backward-compatibility issues; for example if someone was using a
simple "+" as a prerequisite (which is perfectly legal).  So it would
be:

  tgt1 tgt2 ... tgtn &: pre1 pre2 ...

Other versions of make allow both grouped and non-grouped targets in
the same syntax by introducing a grouping syntax, like:

  [ tgt1 tg2 ] tgt3 [tgt4 tgt5] : ...

However I'm not sure that level of complexity is needed or desirable. 
One could still do that with the "whole rule" implementation, at the
cost of repeating the recipe for each separate rule.

Second, I'm not sure that the solution you have is complete because the
additional targets are never registered as files with make.  That means
that only the first target is a known file, etc.  E.g., there's no
reason that this should not work:

  baz : bar

  foo bar &:

If someone runs "make baz" here I would expect make to run the single
recipe to generate both "foo" and "bar", but I'm not sure it will
behave properly in your patch because "bar" is not registered as a file
(as far as I understood what it does).

This relates to my last concern so far: a feature this significant
definitely needs to have tests created for it, both positive and
negative, to show how it works and that it works properly in many
different situations.  There is a test suite available in the GNU make
distribution which is fairly straightforward to use (at least for
simple tests).  Please let me know if you have questions.

And finally, please remember that any feature representing this much
work needs to have copyright assignment papers completed to assign
changes to the FSF.  I see you have assignments for GNU libc; let me
know if you need me to send you details about this.

Thanks again for your interest in making GNU make better!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]