Date: Sun, 28 Mar 2004 15:19:02 +0200 From: Thomas-Martin Seck <tmseck-lists@netcologne.de> To: Oliver Eikemeier <eikemeier@fillmore-labs.com> Cc: freebsd-ports@FreeBSD.org Subject: Re: treating OPTIONS Message-ID: <20040328131902.GB593@laurel.tmseck.homedns.org> In-Reply-To: <4066C41A.90504@fillmore-labs.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040328131902.GB593>