Which ports store/use OPTIONS (/var/db/ports/portname/options)?

Ion-Mihai Tetcu itetcu at people.tecnik93.com
Tue Feb 28 05:46:49 PST 2006


On Tue, 28 Feb 2006 02:39:12 -0800
Jeremy Chadwick <freebsd at jdc.parodius.com> wrote:

> On Tue, Feb 28, 2006 at 09:32:10AM +0100, Clement Laforet wrote:
> > On Mon, Feb 27, 2006 at 12:18:07PM -0500, Chris Shenton wrote:
> > > Other ports don't, like www/apache22.  This is annoying because I
> > > have to remember when I rebuild it, and portupgrade won't get my
> > > needed tweaks like WITH_PROXY_MODULES.
> > > 
> > > For apache22 I've set my needed tweaks in /etc/make.conf but that
> > > doesn't seem the best place, especially since the config names
> > > are so generic, like WITH_SSL_MODULES.
> > 
> > www/apache2* ports can't be converted to OPTIONS since many build
> > time options are not simple defines.
> > 
> > clem
> 
> Likewise, www/cgiwrap can't be fully converted to OPTIONS for this
> reason (i.e. supporting a custom logfile location), and the same for
> www/suphp.

Could you not overload do-configure target so that when `make configure`
your custom configuration script is run ?

> Personally, I've never liked OPTIONS and /var/db/ports.  I consider it
> "another directory I have to worry about", especially if the port
> author changes some of the OPTIONS names between port revisions ("Eh?
> Why is this port building with the wrong settings... *30 minutes
> later* Oh, hrm...").  I'm also not very fond of curses, especially

Indeed when OPTIONS change, either in meaning or in number (OPTIONS
added/removed) currently there's no warning for the user. I have
implemented something in two of my ports for this and I will submit a
patch for bsd.port.mk shortly.

> when it comes to dealing with it over a serial console that lacks
> proper terminal support.
> 
> Additionally, there needs to be dialog --inputbox support for OPTIONS
> to become useful.

And a way to have 2 or more OPTIONS exclude each other, and sub-OPTIONS
based on selected options, etc.

HOWEVER: I recently have got myself a amd64 desktop and installing 750
ports that I had on my i386 desktop was a big pain. Since thing differ
between i386 and 686 (soe ports don't work and the later) I couldn't
use my existing pkgtools.conf, make.conf
and /var/db/ports/portname/options). Since sleeping for two or three
days next to my computer is not something I enjoy and I find inspecting
750 Makefiles and associated config scripts equally stupid, half-way
through the process I was on the point on writing some rather
unpleasant  mails to some maintainers; I will send patches instead.

So yes, OPTIONS are far from being perfect, but they're the best thing
we have and please use them whenever possible.

> I'd rather see both WITH_* and OPTIONS done away with altogether, and
> the entire framework replaced with a tree-based configuration file.
> Actually, this would apply to make.conf.  Something remotely like:
> 
> # Affects both system/kernel and ports
> IPV6 = no
> X11  = no
> 
> # ports tree only
> ports {
>   devel/gettext {
>     EXAMPLES = no
>     HTMLMAN  = no
>   }
>   www/apache20 {
>     KQUEUE_SUPPORT = yes
>   }
>   www/suphp {
>     CHECKPATH = no
>     LOGFILE   = /var/log/suphp.log
>   }
> }
> 
> Some people simply stick all of the WITH_* tweaks into make.conf,
> which I disagree with, since it clutters the file and applies to all
> ports (rather than each individual port).

both can be avoided, e.g. by .include "/etc/make.conf.ports"
in /etc/make.conf and using
.if ${.CURDIR:M*/category/port}
..........
.endif


-- 
IOnut - Unregistered ;) FreeBSD "user"
  "Intellectual Property" is   nowhere near as valuable   as "Intellect"

BOFH excuse #451:
astropneumatic oscillations in the water-cooling




More information about the freebsd-ports mailing list