Re: make: sysV subst with variables

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Jun 01, 2011 at 12:27:52PM -0700, Simon J. Gerraty wrote:
 > >What's an example of the recursive modifier behavior that conflicts
 > >with handling those variables the way you want?
 > 
 > Sure - these are all from my sys.mk and get used heavily.
 > [snip]

Ok, that makes my eyes burn but I think I understand. Symbolically the
variable expansion syntax is supposed

   ${VAR:modifiers}

where modifiers is arbitrary text possibly including variable
expansions, which has to be collected before it can be split into
individual modifiers and applied. The bug is that if it sees
${VAR:${...}} it assumes the internal variable reference is a complete
modifier (or a complete group of modifiers) and if this isn't true
because it's e.g. part of a substitution string, it belches.

 > So this patch adds a check that what Var_Parse() consumed is what we
 > expect in this case it would not be since '/' is not ':', '}' or ""
 > so it consumes up to one of those, with the result that  ApplyModifiers
 > is called with ${BAR}/%.x=% instead.

Wouldn't it be better to collect the complete modifier text up to the
terminating right-brace, do a full variable expansion on it, and only
then split it into individual modifiers and apply them? No, I guess
that breaks things like ${FOO:S/${OLDPATH}/${NEWPATH}/} where either
or both paths contains slashes.

What happens if you have

   MOD=tl:

(note the trailing colon) and write

   ${FOO:${MOD}S/^/blah/}

?

Worse, what about

   ${FOO:${MOD}S/^/${BAR:tl}/}

Currently this works... pretty sure your patch will break it. :(

Also, currently things like

   FOO=dummy
   DUM=S/dum
   ${FOO:${DUM}my/splat/}

are rejected and I think this is a good thing.

Given that the svr4 substitution syntax is already a special case,
maybe the right answer is to make it special in another way and add a
workaround for cases where one wants the substitution LHS to begin
with a variable.

Or... hmm, maybe, since we already insist that a variable reference in
the modifier position is a complete modifier, the right answer is to
demand that it be followed by : or }, and if it isn't, treat it as
plain text rather than a modifier block and therefore part of a svr4
substitution. I believe this is grammatically sound, and it solves
your problem. It does prohibit the case

   MOD=tl:
   ${FOO:${MOD}S/^/blah/}

from above, but I can't think of any particular reason we should cater
to this when it's just as reasonable to write

   MOD=tl
   ${FOO:${MOD}:S/^/blah/}

Implementing it though... will have to have a look.

-- 
David A. Holland
dholland%netbsd.org@localhost