Merging DragonFly make and NetBSD make

Dmitri Nikulin dnikulin at gmail.com
Mon Jun 19 19:23:50 PDT 2006


On 6/20/06, Steve Mynott <steve.mynott at xxxxxxxxx> wrote:
On 6/19/06, Petr Janda <elekktretterr at xxxxxxxxxxxxxx> wrote:
> Has anyone got plans for this? Sure, it's not _highly_ important, but it
> would be nice not to have to do bmake but just make when installing the
> pkgsrc ports now when pkgsrc is the official package management system.
> Im not a C programmer so I cant do it.
Wouldn't it be easiest to simply replace DragonFly's make with
NetBSD's bmake (and make sure
it works with the tree)?
Only if bmake is extended a bit. It's particularly spartan. I find
many of even my own make trees don't work with bmake just because it's
probably the only widely used make without the -C flag. What are we
meant to do then - cd dir; make ...; cd .. ?
I've also never seen it actually work with parallel jobs on pkgsrc nor
the base tree, which is probably a fault of how they're set out. Is it
a build.sh bug that MAKEFLAGS isn't actually passed to make? Using it
for pkgsrc just breaks everything violently.
I don't think either DragonFly's or NetBSD's make is spectacularly
clean. Behold:
} else if (strncmp(line, "include", 7) == 0 &&
   isspace((unsigned char)line[7]) &&
   strchr(line, ':') == NULL) {
That's in parse.c of DragonFly's make. Many more like it. This one is
in a massive while loop which reads straight from the makefile and
re-allocates the line buffer on every iteration, freeing it after a
goto label.
Or maybe have the horrible hack of make under /usr/pkgsrc
transparently invoking bmake :-)
That's really just a convenience. But it could be an interesting
extension to variant symlinks, which I'm sure somebody will find a way
to exploit horribly.
 -- Dmitri Nikulin





More information about the Users mailing list