Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Mar 2008 19:03:02 +0000
From:      RW <fbsd06@mlists.homeunix.com>
To:        freebsd-ports@freebsd.org
Subject:   Re: ports/113132 (make -j patch)
Message-ID:  <20080312190302.5bb86081@gumby.homeunix.com.>
In-Reply-To: <200803121831.43296.mail@maxlor.com>
References:  <200803121311.51383.mail@maxlor.com> <20080312154725.705e141c@gumby.homeunix.com.> <200803121831.43296.mail@maxlor.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 12 Mar 2008 18:31:36 +0100
Benjamin Lutz <mail@maxlor.com> wrote:

> On Wednesday 12 March 2008 16:47:25 RW wrote:
> > On Wed, 12 Mar 2008 13:11:51 +0100
> > Benjamin Lutz <mail@maxlor.com> wrote:
> > > This patch has been sitting in GNATS for a couple of months now:
> > >
> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/113132
> > >
> > > I've received a few mails from people reporting success, and none
> > > reporting that bad things have happened. Is it possible to get
> > > this committed?
> >
> > I'm not keen on the way MAKE_JOBS_WHITELIST is implemented as a
> > list. It seems to be out of step with the way similar problems are
> > handled elsewhere. I would have expected a simple flag that can be
> > set per port using portsconf, pkgtools.conf, etc.
> 
> portconf and pkgtools.conf are files that are used by tools external
> to the base ports system (portmaster and portupgrade). The ports
> makefiles do not read them. .

Portconf is a simple script that's executed from /etc/make.conf, so it
gets picked-up by everything.

> The traditional place to put port
> configuration info is /etc/make.conf

Yes, conditional definition in make.conf was the "etc" 

> Since using the whitelist is not intended to be an officially
> supported feature, but only exists to make life a bit easier for
> people who are debugging the ports or willing to experiment, I expect
> that on 99% of FreeBSD systems, the whitelist will not be specified
> at all. 

But it's actually easier to do it consistently with the existing
conventions, than the way you have it

> I therefore see no reason to increase the complexity of the
> whitelist parsing code by introducing non-make-compatible syntax.

It eliminates the whitelist altogether.  A FORCE_MAKE_JOBS  flag would
simply be ORed with the ALLOW_MAKE_JOBS flag. 

The also allows users to define their own logic in make.conf, for
example to force parallel building for all ports that aren't on a
user-defined blacklist. 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080312190302.5bb86081>