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