Date: Fri, 30 Jul 2004 23:07:05 +0300 From: Ion-Mihai Tetcu <itetcu@people.tecnik93.com> To: Ulrich Spoerlein <q@uni.de> Cc: Radim Kolar <hsn@netmag.cz> Subject: Re: configuring ports via Makefile.local Message-ID: <20040730230705.3e803f8e@it.buh.tecnik93.com> In-Reply-To: <20040730184715.GA768@galgenberg.net> References: <20040727122823.40c6c3c5@it.buh.tecnik93.com> <BF9C33C8-DFB4-11D8-BCFE-00039312D914@fillmore-labs.com> <20040730165444.GA36115@sanatana.dharma> <20040730184715.GA768@galgenberg.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 30 Jul 2004 20:47:15 +0200 Ulrich Spoerlein <q@uni.de> wrote: > On Fri, 30.07.2004 at 18:54:44 +0200, Radim Kolar wrote: > > Supporting Makefile.local is a good idea. It allows per-port > > configuration without using external tools like portupgrade and > > without making some obscure constructs in make.conf. It is easy to > > understand and port subsystem already handles it for last 5 years > > and there is a policy about not committing makefile.local into ports > > tree. There is no reason for throwing makefile.local away. > > It only works with a R/W ports tree, and only if that ports tree is > not shared across several machines, as is the common case. Therefore > these options need to be host-specific. Putting them into the ports > tree is a bad idea IMHO. You loose all changes when doing 'rm -rf > /usr/ports' for example. > > > > To make it `supported' it has the be documented somewhere, which > > > is something I won't like to see. > > Do you want to see OPTIONS= as only method supported? Converting all > > ports into OPTIONS= is also solution of this problem. > > Please NO! OPTIONS are very ugly, IMHO. Imagine installing a new > system and running a massive portinstall. setenv BATCH=YES or WITH_BLA_BLA=CUCU for this case works. > The only real solutions IMHO are the make.conf approach (which works > in all cases), or the pkgtools.conf approach (which horribly fails in > the 'fresh install' case, but is otherwise a good solution). > > It looks like people are not aware of the possibilities with > make.conf, which led to all those half-working methods. OPTIONS are a very good thing, IMO. The lack some features, but are easy to use, esp. for newbies. Looking_at_and_understanding a Makefile takes time. After doing a few ports I can say I understand about 75% of what bsd.ports.mk _does_and_how_ , but bsd.python.mk for example is uncharted land for me. Plus OPTIONS (seems to want to) provide some sort of versioning.. Recently andreas@ pointed me that wanting to change the meaning of WITHUOT_SOMETING would at least confuse users. This versioning should somehow warn users about this kind of problems. -- IOnut Unregistered ;) FreeBSD "user"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040730230705.3e803f8e>