Date: Sun, 28 Sep 2003 16:09:15 -0400 From: Richard Coleman <richardcoleman@mindspring.com> To: Ulrich Spoerlein <q@uni.de> Cc: ports@freebsd.org Subject: Re: First attempt at unifying WITH_* options Message-ID: <3F773FEB.6010809@mindspring.com> In-Reply-To: <20030928155434.GA770@galgenberg.net> References: <20030928155434.GA770@galgenberg.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I want to voice my support for adding this type of facility to the port
system for FreeBSD. This is sorely needed.
I haven't tried the patch yet. But from a brief glance, it apppears to
be exactly what we need.
We also need a place for the port maintainer to record a summary of the
options, as well as any comment that is specific to that option and
port. For instance, if each port had a file "pkg-options", this could
print:
make print-option
WITH_TCL - Add tcl support. Currently experimental.
WITH_TK - Add tk support. Currently broken.
WITH_FOO - Add support for foo. Developers only.
etc.
Richard Coleman
richardcoleman@mindspring.com
Ulrich Spoerlein wrote:
> Hello all,
>
> attached is a small patch to bsd.port.mk and a new file I dubbed
> bsd.options.mk. I also included a diff against the QuakeForge port,
> which shows how to use the new PROVIDE_OPTIONS and DEFAULT_OPTIONS
> variables (sorry for the long diff, it was necessary because of the
> PLIST_SUB)
>
> What this patch does is this:
>
> A port specifies PROVIDE_OPTIONS= sdl xmms.
> A user can then lookup these options with 'make print-options' and set
> them in the build process. There is also a print-options-recursive
> target which prints all the options for the build/run depends. This
> "fixes" one grief I always had with user-settable options. You want to
> install some port, which depends on another port. This other port _can_
> use SDL for example. You have SDL installed and want the port to use
> SDL. Now you can either watch the complete build process and interrupt,
> when a dependancy get's pulled in which _can_ use additional software
> you have installed, or you manually check all not-already-installed
> dependancies and see if they can use additional components which you
> would like them to use.
> Of course you could set WITH_SDL=yes in /etc/make.conf, but maybe there
> is port X which is broken when using SDL so you don't want that
> particular port to be build with SDL.
> Note: You can't use this with portupgrade, because it will not
> pre-install dependancies when installing a new port. That means you can
> have your MAKE_ARGS hash loaded with options, but when you install one
> port, and the Make-Magic pulls in another Port, it's build flags are not
> set (I hope you can follow me here :)
>
> bsd.options.mk then checks to see if either WITH_SDL=yes/WITHOUT_SDL=no
> or WITH_SDL=no/WITHOUT_SDL=yes is specified. This allows for overriding
> port-defaults set in DEFAULT_OPTIONS.
>
> An additional benefit of this centralized approach is, that all those
> "shlib version bump chases" get vastly simplified.
>
> Implementing an interactive 'menuconfig' target is very easy (some
> people have requested this...)
>
> Issues to resolve:
> - Right now, a port can't use 'print-options' without pulling in all the
> LIB_DEPENDS/CONF_ARGS stuff. So either another Variable is needed or the
> stuff in bsd.options.mk has to be overrideable.
> - I'm defaulting to LIB_DEPENDS right now, obviously this is only
> correct if the port links agains libxmms for example. But there are
> enough ports, that only run-depend on xmms (the binary). I'm not quite
> sure how to fix this.
> - I'm using tons of Variables right now (OPTIONS_xmms, OPTIONS_sdl, ...)
> perhaps this should be changed to one variable, adding all the _set_
> options and removing the _unset_ options. Something like FLAVOR on
> OpenBSD.
>
> Please try the patches and tell me what you think.
>
> Ulrich Spörlein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F773FEB.6010809>