From owner-freebsd-ports@FreeBSD.ORG Sun Mar 28 05:19:03 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 94ACC16A4CF for ; Sun, 28 Mar 2004 05:19:03 -0800 (PST) Received: from smtp2.netcologne.de (smtp2.netcologne.de [194.8.194.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3780743D1F for ; Sun, 28 Mar 2004 05:19:03 -0800 (PST) (envelope-from tmseck-lists@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-213-196-192-78.netcologne.de [213.196.192.78]) by smtp2.netcologne.de (Postfix) with SMTP id 666233A179 for ; Sun, 28 Mar 2004 15:19:01 +0200 (MEST) Received: (qmail 3065 invoked by uid 1001); 28 Mar 2004 13:19:24 -0000 Date: Sun, 28 Mar 2004 15:19:02 +0200 From: Thomas-Martin Seck To: Oliver Eikemeier Message-ID: <20040328131902.GB593@laurel.tmseck.homedns.org> References: <20040327200136.31711.qmail@laurel.tmseck.homedns.org> <1080436501.75008.5.camel@hood.oook.cz> <20040328112228.GA593@laurel.tmseck.homedns.org> <4066C41A.90504@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4066C41A.90504@fillmore-labs.com> User-Agent: Mutt/1.4.2.1i Organization: private site in Germany X-PGP-KeyID: DF46EE05 X-PGP-Fingerprint: A38F AE66 6B11 6EB9 5D1A B67D 2444 2FE1 DF46 EE05 X-Attribution: tms cc: Pav Lucistnik cc: freebsd-ports@FreeBSD.org Subject: Re: treating OPTIONS 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: Sun, 28 Mar 2004 13:19:03 -0000 * Oliver Eikemeier (eikemeier@fillmore-labs.com): > Thomas-Martin Seck wrote: > >[...] > > > >Autodetection is not bad as such, but it needs to be overridable and it > >should not be allowed to mess with OPTIONS. > > I agree that there should be a way to turn it off, but why should the port > not preselect OPTIONS that activate features that are available on the > current system? I your case you would get LDAP support preselected, but > could simply turn it off? In my opinion, OPTIONS should be static; it should represent the default feature set the maintainer or the software author has/had in mind (that is why I do not consider it to be a problem when OPTION's datafile is not read in the BATCH and PACKAGE_BUILDING cases because you just have to get the parser right, instrumenting the fact that you get a WITHOUT_FOO for every WITH_FOO for free). Autotuning this default option set can have interesting effects in a package building environment, effectively it forces you to build every package in a clean room environment to avoid dependency pollution.