From owner-cvs-all@FreeBSD.ORG  Mon Aug 29 14:39:44 2011
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Delivered-To: cvs-all@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 1033)
	id A613C106566B; Mon, 29 Aug 2011 14:39:44 +0000 (UTC)
Date: Mon, 29 Aug 2011 14:39:44 +0000
From: Alexey Dokuchaev <danfe@FreeBSD.org>
To: Chris Rees <crees@freebsd.org>
Message-ID: <20110829143944.GA94377@FreeBSD.org>
References: <201108261828.p7QISje3085996@repoman.freebsd.org>
	<20110826200234.GA8743@FreeBSD.org>
	<CADLo839MkBrHQRz4B4XRTaSEO51uC+XsQXnc3OrZjiMf2Bkkvw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CADLo839MkBrHQRz4B4XRTaSEO51uC+XsQXnc3OrZjiMf2Bkkvw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Koop Mast <kwm@freebsd.org>, cvs-ports@freebsd.org, cvs-all@freebsd.org,
	ports-committers@freebsd.org
Subject: Re: cvs commit: ports/textproc/ots Makefile
X-BeenThere: cvs-all@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: **OBSOLETE** CVS commit messages for the entire tree
	<cvs-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-all>
List-Post: <mailto:cvs-all@freebsd.org>
List-Help: <mailto:cvs-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Aug 2011 14:39:44 -0000

On Mon, Aug 29, 2011 at 02:03:05PM +0100, Chris Rees wrote:
> 2011/8/26 Alexey Dokuchaev <danfe@freebsd.org>:
> > Just replying to a random MAKE_JOBS_UNSAFE commit. šI have a suggestion
> > which I think would help us to fix parallel builds when portmgr@ decides to
> > start running -exp runs with forced MAKE_JOBS: every time one of us marks a
> > port as MAKE_JOBS_UNSAFE, should provide a short comment on the nature of a
> > failure.
> >
> > Perhaps MAKE_JOBS_UNSAFE knob could be refactored into something similar to
> > other "brokenness" knobs and tought to accept a reason string, while "yes"
> > value could still be used for cases when exact cause of breakage is not so
> > obvious.
> 
> There's no reason a comment can't be put into MAKE_JOBS_UNSAFE;

Indeed.  I just wasn't sure if it's being checked against "yes" or simply if
defined.

./danfe