"Simon J. Gerraty" <sjg%juniper.net@localhost> writes:
> Martin Husemann <martin%duskware.de@localhost> wrote:
>
> I would expect it is because the value $file needs to be used to set
> variables like .ALLSRC etc, which exposes it to Var_Parse which
> interpret that as equivalent to ${f}ile.
>
>>
>> target: $$$$file
>> (recipe)
>>
>> that works here, and not, say, $$$$$file ?
>
> an odd number of $'s isn't going to work.
>
> Assuming I'm correct above, the $$$$file would get seen as $$file
> by Var_Parse (or whatever) and result in the correct value of $file in
> vars like .ALLSRC
I think the real issue is:
gmake has a behavior that the world considers sane. I found it
unsurprising, at least.
I don't see how a user writing a makefile can guess at how many times
a string will be treated like a variable. It seems like when it is
first written, it should be, and then if it is explicitly evaluated,
but otherwise, no.
While I can see that 4 $ are needed to get $file into .ALLSRC, it
doesn't make sense that this should be expanded again for the individual
rule, speaking as a user rather than a make maintainer. (I can just
barely or not quite follow Roland's explanation at
https://github.com/NetBSD/src/blob/59a3d6f48af7/usr.bin/make/unit-tests/dep-var.mk#L29
)
While it's obvious to me that people shouldn't use $ in filenames, just
like they shouldn't use ' ', it doesn't seem like it would go well to
file bug reports against projects that do that :-(
> Perhaps a special variable name other than $ (ie $$)
> to represent a literal $ - something that Var_* can know to just leave
> alone, would help while not making the parsing insanely complicated.
That just seems like another incompatibility between BSD make and gmake.
From the pkgsrc viewpoint, we end up forcing gmake if the makefile isn't
ok with both, because most upstreams are writing for gmake anyway.
> Note even $$$$file does not result in useful .ALLSRC
>
> the-thing: $$$$file
> @echo 'We have ${.ALLSRC}'
>
> outputs
>
> We have ile
Is there a desired behavior that this double-expansion scheme is
producing now?
Attachment:
signature.asc
Description: PGP signature