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

[Kaz Kylheku (gmake)]

On 2019-03-13 05:28, Paul Smith wrote:
> 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.

Hi Paul.

I will re-work it to use &: it's a lot better!

We don't have to care about this case, do we?

   a b c &: : prereq   # :& is an odd target name, eek!

I take it I should post to the Savannah item above?

I have a Savannah account due to having a few projects there.
I don't have permission to upload patches to the GNU Make project,
just to open tickets and comment.

> 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] : ...

This is very similar to an original design that I proposed in a 
discussion
in comp.unix.programmer. The proposal was to parenthesize all of the
targets like this:  ( tgt1 ... tgtn ) : prereqs ...

Even just this is quite a bit more work in the parsing.

If multiple target groups are allowed, also more complexity in the
file registration logic.

> However I'm not sure that level of complexity is needed or desirable.

Indeed, would be the use case? When would there be a generic rule
which updates differently-sized subsets of target pairs? How would the
recipe know what it's supposed to build?

We can imagine a case where targets are organized into tuples of
equal arity:

  [ tgt1.1 tgt1.2 ] [ tgt2.1 tgt2.2 ] : ...

This case calls for a pattern rule. Because surely, the elements of
these tuples must follow a naming pattern in which a common stem
is identifiable. If they don't follow such a naming pattern, how will
the recipe know what to build? There would have to be a new automatic
variable which gives the recipe the entire tuple of targets.
The $@ variable only indicates the one target which triggered the rule,
which could be any element of the tuple. Pattern rules address that
with the stem variable $*; there just has to be commonality in the
non-stem parts of the target names that the rule knows about.

> Second, I'm not sure that the solution you have is complete because the
> additional targets are never registered as files with make.

Funny you should say that because I had a bug like this in a
"first cut" at this, so I know exactly what you're talking about!

The algorithm for registering the targets is not altered (including
double colon handling). Each of the targets is registered in the
same way as before; the first target isn't special in any way.

If the flag indicates that they are to be linked as "also makes",
then, as they are being registered, a parallel list of "dep" objects
is built up, one for each registered file

Then, in a second pass, the files are re-visited (by traversing
this dep list, whose entries have a "struct file *" pointer to
each corresponding file). For each file, a copy of that whole
dep list is installed as its also_make list, resulting in a
"full mesh".

(P.S. there is a memory leak because I don't just use the original
dep list for the last file; a duplicate is made for that one too,
and the original is not freed. I already fixed this.)

I didn't want to start writing a bunch of tests before getting comments
about this feature: is there interest in it at all, how is the syntax,
and so on.

> And finally, please remember that any feature representing this much
> work needs to have copyright assignment papers completed to assign
> changes to the FSF.

Is the threshold that low?

This is just a few lines of code in some existing functions.

I'm smiling contently at the low amount of effort and LOC expenditure.

Basically, the actual algorithm for updating the files together
is already there, thanks to pattern rules. So unless I'm missing 
something,
this is just a matter of connecting a few dots with some chains of
dep objects.  Essentially, it's just exposing existing semantics by
allowing it to be configured with some new syntax.

Cheers ...