First attempt at unifying WITH_* options

Richard Coleman richardcoleman at
Sun Sep 28 13:09:08 PDT 2003

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 

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.


Richard Coleman
richardcoleman at

Ulrich Spoerlein wrote:
> Hello all,
> attached is a small patch to and a new file I dubbed
> 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
> 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 :)
> 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 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

More information about the freebsd-ports mailing list