From owner-freebsd-ports@FreeBSD.ORG Mon Mar 22 06:13:57 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61ACC16A4CE; Mon, 22 Mar 2004 06:13:57 -0800 (PST) Received: from postman.arcor.de (postman4.arcor-online.net [151.189.0.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9FF243D49; Mon, 22 Mar 2004 06:13:56 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i2MEDsD2022246 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 22 Mar 2004 15:13:55 +0100 (MET) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1B5QBa-0004hK-2e; Mon, 22 Mar 2004 15:13:50 +0100 Message-ID: <405EF49D.7030800@fillmore-labs.com> Date: Mon, 22 Mar 2004 15:13:49 +0100 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: harti@freebsd.org References: <20040322143029.A55144@beagle.fokus.fraunhofer.de> In-Reply-To: <20040322143029.A55144@beagle.fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: ports@freebsd.org Subject: Re: ports infrastructure changes for standards/57295 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2004 14:13:57 -0000 Harti Brandt wrote: [...] > The third problem lies in the bsd.ports.mk. Version 1.315 added a speedup > by passing certain variables to sub-makes via command line assignments > (look for __softMAKEFLAGS). This wont work with the patched make, because > these variables are not-overrideable by submakes and this breaks any build > of dependent ports. I think this problem causes most breakage. I was able > to circumvent the problem by specifying NOPRECIOUSMAKEVARS=yes to make, > but don't know whether this is the correct thing to do. And, to be honest, > I don't fully understand what this __softMAKEFLAGS thing does. So could > please someone help me with this? I am working on a revised OPTION handling patch, which touches more than half the cases where __softMAKEFLAGS is used (son-of-PR 64233, but you don't need to read the patch in there, I'm doing something different). I guess I should be able to come up with something that is compatible with the old and the new make, so perhaps we could discuss this off-list. Oliver