bug-make
[Top][All Lists]
Advanced

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

Re: Suggested feature design for https://savannah.gnu.org/bugs/?42125


From: Paul Smith
Subject: Re: Suggested feature design for https://savannah.gnu.org/bugs/?42125
Date: Sat, 23 Apr 2016 19:59:49 -0400

On Thu, 2016-04-21 at 08:29 +0100, Tristan Wibberley wrote:
> x86-64 x86 armel: %=build/%/main.o: main.c ; true 
> factors :: path=subst : prerequisites ; recipe

Almost all the syntax you suggest that uses "=" is not possible, because
it already has a well-defined meaning: it defines target-specific
variables.

The value of a variable can be anything: we can't parse that value
looking for more syntax to see if it's not intended to be a variable
assignment.  Once we detect an "=" in a context where a variable
assignment is legal, we MUST assume the entire rest of the logical line
is the value to be assigned.

In the first line I quote above, for example, this syntax is legal today
and sets the target-specific variable "%" to the string "build/%/main.o:
main.c ; true" for each of the targets x86-64, x86, and armel.  And the
second example sets the variable "path" to the value "subst :
prerequisites ; recipe" for the target "factors".


There has been discussion in the past of allowing multiple targets to be
generated in a single explicit rule and also allowing a single pattern
rule definition to actually create multiple targets (the inverse of the
current behavior).

What I suggested at the time was to create a new type of separator;
today we have ":" and "::" and I envisioned two new separators, "&:" and
"|:" which would explicitly choose whether all the targets are created
from a single invocation of the recipe ("&:") or each target is created
by a separate invocation of the recipe ("|:").

This would make ":" a special case which would default to the "|:"
behavior for explicit rules and the "&:" behavior for pattern rules, but
you could use the longer form for any rule definition.

However, this was not implemented (at least, not fully implemented...
ISTR there were some patches sent around that at least started to make
this possible).



reply via email to

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