Re: Surprising make behavior

["Simon J. Gerraty" <sjg%juniper.net@localhost>]

Greg Troxel <gdt%lexort.com@localhost> wrote:
> 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
> )

Reminds me of an interview question I use for people who claim to grok
make - all about understanding when/how variables are evaluated.
bmake and gmake produce identical results btw so doesn't matter which
one is familar with - if you understand how make works you can provide
the correct answer.

> 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 :-(

A waste of time I'm sure.
And pitty folk brought up on windoze where \ is directory separator.

> > 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.

Perhaps, but I find gmake a rather blunt instrument compared to bmake.
I haven't used it seriously for at least 20 years.

I've previously asserted that gmake could not do something like
dirdeps.mk,  for grins I actually implemented dirdeps.gmk a while back.
http://www.crufty.net/sjg/docs/gmake-dirdeps.htm

It is far more effective than I initially thought would be possible, and
while it can only handle the basics, is probably still a good way to
orchestrate a complicated build.

> 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.

Yes,  that makes sense.

> Is there a desired behavior that this double-expansion scheme is
> producing now?

Yes, it allows defering evaluation of nested variables,
without it you could not do things like the M_whence example I gave
earlier.

bmake's modifier syntax is unfortunately terse, at least for the old ones.
There is huge power there, but they can look like line-noise
and being able to capture complicated modifier combinations in variables
is very handy.

--sjg