pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg/42704: Adding support for bmake as a pkgsrc tool (ala gmake)

The following reply was made to PR pkg/42704; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: pkg/42704: Adding support for bmake as a pkgsrc tool (ala gmake)
Date: Fri, 05 Feb 2010 06:32:08 +0700

     Date:        Tue,  2 Feb 2010 23:55:05 +0000 (UTC)
     From:        Joerg Sonnenberger <>
     Message-ID:  <>
   |  Frankly, I would just mark them as broken with the system make.
 That's certainly a possibility, I wouldn't mind marking half
 of gnome as broken (with the percentage probably growing over time).
   |  If someone bothers enough, he/she can always bootstrap to get the modern
   |  make.
 For me, at least, that's practical iff it is automated as part of pkgsrc.
 I tear down and rebuild the entire sandbox (starting from the release set
 files) for every package I build - extract the release, pkg_add the
 dependencies, then build, make a package, and remove it all again.
 "bootstrap" works only if it is automated (the way a new required set
 of pkgtools is automated, for example.)   If there's some automated way to
 do it (whether or not that means running an additional command), then I
 could deal with it (but I don't want to build version dependent dependencies
 into my build scripts, so I don't want to just always "pkg_add bmake-*" as
 [art of the setup process, as on anything other than NetBSD 4, that's
 either already done, or not required.
   | I explicitly do not want to have another special case for this.
 For just dealing with the NetBSD 4 (and earlier, but that doesn't matter)
 make bug, and the bizarre gnome packages with depend lists beyond
 comprehension, I'd sympathise.
 But I think allowing bmake as an alternative make is more useful than that.
 At the minute, when a few feature is added to make, /usr/src gets to use
 it 5 minutes later.  pkgsrc probably has to wait 5 years (two full
 release cycles, at least) - before then you cannot assume the system make
 in a supported system has the new feature.   That's very hard to do, especially
 for new developers who have no idea that this particular feature is new
 (or within 2 releases new).   That's the primary advantage of allowing
 devel/bmake as a supported tool I think, and given just how small the
 change is, I'd suggest it is one well worth making.

Home | Main Index | Thread Index | Old Index