pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Surprising make behavior
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
Home |
Main Index |
Thread Index |
Old Index