configuring ports via Makefile.local
eikemeier at fillmore-labs.com
Fri Jul 30 16:12:28 PDT 2004
Ion-Mihai Tetcu wrote:
> On Fri, 30 Jul 2004 20:47:15 +0200
> Ulrich Spoerlein <q at 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.
One of the problems is that you have to read (and understand) the ports
Makefile to know which options you can configure with Makefile.local.
One port might do
Which might give stange results when WITH_TLS=yes is set in
Makefile.local. IMHO it is one of the more obscure features of
bsd.port.mk that should go 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.
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.
>> Please NO! OPTIONS are very ugly, IMHO. Imagine installing a new
>> system and running a massive portinstall.
> setenv BATCH=YES
> 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,
>> 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
>> 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.
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.
More information about the freebsd-ports