[SUBDIRMK RFC 6/7] README: v2: Draft - macro assistance facility [and 1 more messages]

[Ian Jackson]

Ian Jackson writes ("[SUBDIRMK RFC 6/7] README: v2: Draft - macro assistance facility"):
> +DRAFT - MACRO ASSISTANCE FACILITY
> +---------------------------------
> +
> +Thanks to Mark Wooding.

In the pub, we discussed this more.  We concluded that the "extra"
variable is not needed.  So:

> +        &:macro NAME
> +        STUFF
> +        &:endm
> +
> +expands to
> +
  +        define NAME
  +        STUFF [with $-doubling initially enabled]
> +        endef

> +and
> +
> +        &(NAME ARG,ARG,...)
                  ^^^^^^^^^^^ $-doubling enabled until next paren
> +
> +expands to
> +
  +        $(eval $(call NAME,ARG,ARG,...))

Ian Jackson writes ("Re: [SUBDIRMK RFC 6/7] README: v2: Draft - macro assistance facility"):
> >   &[macroname   => $(eval $(call %macroname etc.
> 
> We might in any case want to have "&[macroname", or "&{macroname",
> rather than "&(macroname", for two possible reasons:

I'm still unsure about this.  With the above it is indeed a variable
and of course make functions are $( ) to invoke.  But this thing
expands to nothing.

There are in fact two kinds of `macros':

Normal macros: defined with "define" or "=" (not $-doubled); invoke
with "$(call )"; expands to some text; cannot generate rules and
variable settings but only bits and pieces.

These new macros: defined with "&:macro" (or "define" plus "&$+" or
"define" with manual $-doubling); invoke with "&(...)"; can generate
rules, variable settings, etc.; expands to nothing but you expand it
only at the toplevel unless you're mad.

Maybe
 &(NAME ARG,ARG,...) => $(call NAME,ARG,ARG,ARG)
 &{NAME ARG,ARG,...} => $(eval $(call NAME,ARG,ARG,ARG)) [ARGs $-doubled]

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.