Re: Merging DragonFly make and NetBSD make

["Dmitri Nikulin" <dnikulin@xxxxxxxxx>]

On 6/20/06, Steve Mynott <steve.mynott@xxxxxxxxx> wrote:
> On 6/19/06, Petr Janda <elekktretterr@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