Date: Sat, 31 Jul 2004 13:44:57 +0300 From: Ion-Mihai Tetcu <itetcu@people.tecnik93.com> To: Oliver Eikemeier <eikemeier@fillmore-labs.com> Cc: Radim Kolar <hsn@netmag.cz> Subject: Re: configuring ports via Makefile.local Message-ID: <20040731134457.0b88cd39@it.buh.tecnik93.com> In-Reply-To: <069094C0-E27E-11D8-B327-00039312D914@fillmore-labs.com> References: <20040730230705.3e803f8e@it.buh.tecnik93.com> <069094C0-E27E-11D8-B327-00039312D914@fillmore-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 31 Jul 2004 01:13:11 +0200 Oliver Eikemeier <eikemeier@fillmore-labs.com> wrote: > Ion-Mihai Tetcu wrote: > > > On Fri, 30 Jul 2004 20:47:15 +0200 > > Ulrich Spoerlein <q@uni.de> wrote: [ ... ] > >> 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 portstree 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. > > I even want to be able to configure ports that have absolutely no > support for optionsNG, by prasing the Makefile for WITH(OUT)_ tests. > Of course you will have limited funtionality, since no explanations of > the options are available. Currently the development has been delayed, > due to the localpkg breakage. Yes, a heads-up would have been nice. Does it make sense to produce patches to convert ports without OPTIONS to OPTIONS now or one should wait until optionsNG ? Does it makes sense to convert to options at all ? > >> 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. > > One of the design goals for optionsNG was that it should be totally > unintrusive. This means especially that an unconfigured port builds > with a default configuration, like it has always done. Popping up > dialogs without being told so is one of the worst features of > classical OPTIONS, IMHO. > > >> 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). > > at least pkgtools.conf needs to be supported, since it is so wildly > popular. Yes, please. And Radim's portindex too, if it's not to much to ask; it's very nice to have your INDEX rebuilt in 2 minutes ;) > >> It looks like people are not aware of the possibilities with > >> make.conf, which led to all those half-working methods. > > I think the make.conf approach, or similar ones like penv are fragile > and should only used by experts. I won't recommend it as a general > means to configure ports. One repocopy might break them, and it is > easy to make mistakes. Also it is hard to find the configuration for a > port. Said that, it might really work well for experts that exactly > know what they are doing. > > > 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. > > Another thing that is a strict no-no in my book is that users that > have configured their ports by portupgrade or similar methods are > suddenly no longer able to do so, because maintainers gratiously > change from WITH_* to WITHOUT_* or WITH_* && !WITHOUT_* or similar > constructs. I see this as a major POLA violation. Yes, it is. One question: why do we (still) have WITH_* and WITHOUT_* both definable in a Makefile ? I'm always confused by those. Shouldn't there be only WITH_* in Makefiles and default to off if that's what the maintainer thinks ? E.g. .if defined(WITHOUT_DEBUG) CONFIGURE_ARGS+= --disable-debug .else CONFIGURE_ARGS+= --enable-debug .endif could be .if defined(WITH_DEBUG) CONFIGURE_ARGS+= --enable-debug .else CONFIGURE_ARGS+= --disable-debug .endif Of course, this assumes options. > Any port that uses optionsNG should behave like before when a user > choses to use other means than optionsNG to configure the port. So > it's an optional feature, but not required. My want list for options ;) contains: - have a way to output something to the user _before_ the options blue screen -- IOnut Unregistered ;) FreeBSD "user"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040731134457.0b88cd39>