On 24 Apr 2016 01:00, "Paul Smith" <psm...@gnu.org> wrote:
> 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 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.
- a declarative comprehension syntax (like list comprehensions) is
available to repeat a rule definition succinctly based on a set of factors
such as configuration/platform names.
http://www.secnetix.de/olli/Python/list_comprehensions.hawk
https://en.wikipedia.org/wiki/Set-builder_notation.
- 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_somename:=\
subst=fn_name\
future_hook=fn_name2
:=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?
Regards
Tristan
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
