On 24 Apr 2016 01:00, "Paul Smith" <address@hidden
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
The strangest thing. I did a test quite carefully with just one line to see that make reported an error for the presence of an equal sign and it did but now it doesn't! I clearly did something else odd that made it invalid but I don't know what.
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 ("|:").
I think that method leaves a limit in make that already causes people to avoid make so I'm worried that adding the feature that way will be work that doesn't help the engineering userbase much. I love your syntax though.
Although I messed up in my tests of what syntax I could use, I intended very strongly to produce something that is currently invalid so existing makefiles do not get broken and can be combined with new ones using only copy and paste or "include". I think these things become important to allow users to scale up their activities with multiple engineers and low communication overhead.
The general form I would like to propose for a variety of engineering reasons is:
- base form for a rule that generates many targets from just one invocation where it is an error for any of those targets to remain not updated after the recipe is executed.
- base form works much like implicit rules today, a template for a rule which matches a target that's needed against a pattern and using similar patterns to define the co-targets and prerequisites.
- the pattern is not required to cause this behaviour but it always works like that for all forms of target - for predictable behaviour on minimum knowledge.
- the comprehension's behaviour can be tuned by decorating an existing rule in order to do things like "define the same rule pattern for each platform" then later on "make it so that a specific artifact is <platform>_dbg" followed some hours later by "reset to the normal behaviour". All with minimum change to the rule's definition while making it easy for engineers to choose to ensure that they and other's will see and rapidly understand the intention of such a change to that rule via a diff tool.
- The decoration feature should support more advanced scripting so the choice of adding _dbg is controlled by a separate spec file and can also force one or more of the targets to be invalid if that file changes.
- the behaviour of .SECONDEXPANSION is default for such rules or controlled by the decorator.
Now, its a lot of work to achieve all of that but if the initial syntax is chosen well then the work can happen in many phases.
Here's another syntax suggestion:
'\n:=[decorator-name|][domain]:' means rule generation with a comprehension (ie, assign several rules via a template over several key factors) - this syntax is currently invalid. "domain" is a list of words which are applied to the targets and prerequisites to create multiple rules of the same form. Initially only :=: (no decorator nor domain) is supported.
1) support existing implicit rule syntax - only parser,make database, recipe executor changed and comment added to make database output. I suspect that each rule can already be flagged separately for second expansion so that can be enabled for these rules from the start. BUT, it is an error if any target is not updated when the recipe runs.
:=: %.o %.d: %.c | $$(@D)/
2) support a new "cross-product mode" for substitution variables which substitutes all % symbols in the replacement instead of only the first. This mode is always used for the substitution in this new rule syntax but I will use the current substitution syntax in lieu of a new one.
3) support non-empty domain with cross product rules to generate many rules of the same form
:=x86_64 x86 armel: %=%/%%.o %/%%.d: %=%/%%.c | $$(@D)/
4) support decorator. the decorator's function hooks into the pattern substitutions to modify their behaviour. This way an individual file can be switched in all targets and all prerequisites, for example to choose a debug or trace logging build of a specific translation unit without modifying anything else. The interface to the decorator function can be enhanced later if necessary (for example special variables available to the function to access and modify extended flags for the rule and all sorts would be possible.
:=decorator-name|x86_64 x86 armel: %=%/%%.o %/%%.d: %=%/%%.c | $$(@D)/
All this should be possible without anything really difficult and it should limit future parser issues by consuming very little of the limited space for extension - although I don't know what to do about the syntax for cross-product substitutions.
Also, make database dump output needs to be considered each step.
What do you think?