configuring ports via Makefile.local

Ion-Mihai Tetcu itetcu at people.tecnik93.com
Sat Jul 31 03:46:07 PDT 2004


On Sat, 31 Jul 2004 01:13:11 +0200
Oliver Eikemeier <eikemeier at fillmore-labs.com> wrote:

> Ion-Mihai Tetcu wrote:
> 
> > On Fri, 30 Jul 2004 20:47:15 +0200
> > Ulrich Spoerlein <q at 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"



More information about the freebsd-ports mailing list