Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Mar 2004 17:04:50 +0100
From:      Thomas-Martin Seck <tmseck-lists@netcologne.de>
To:        Oliver Eikemeier <eikemeier@fillmore-labs.com>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: default OPTIONS aren't the default when BATCH is set
Message-ID:  <20040313160450.GA3436@laurel.tmseck.homedns.org>
In-Reply-To: <4053207E.4000000@fillmore-labs.com>
References:  <20040313110145.763.qmail@laurel.tmseck.homedns.org> <4053207E.4000000@fillmore-labs.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Oliver Eikemeier (eikemeier@fillmore-labs.com):

> Thomas-Martin Seck wrote:
> 
> >* Sergey Matveychuk <sem@ciam.ru> [gmane.os.freebsd.devel.ports]:
> >
> >
> >>There is a workaround while it's not fixed:
> >>OPTIONS=        SOME_DEFAULT "..." on
> >>WITH_SOME_DEFAULT?=     yes
> >
> >That looks bogus to me. The ?= does not make sense for variables
> >which are checked for definedness only (?= is the same as = since you
> >cannot 'unset' the variable on the commandline) and IMO it is sufficient
> >to fix the port's options parser to check for WITHOUT_OPTION_FOO when
> >'foo' defaults to 'on'. At least this is how I do it in my ports.
> 
> The whole WITHOUT_* stuff is a misfeature IMHO. What options do I get
> when I do
> 
>  cd textproc/libxml2; make WITHOUT_PYTHON=yes WITH_SCHEMA=yes 
>  WITH_XMLLINT_HIST=yes

May I ask you to forward this to the maintainer of said port? This has
nothing to do with the topic of this discussion.

> (which I have in pkgtools.conf). Now I (and lots of other port users)
> are chasing ports that are early adaptors of buggy features. Not very
> pleasing.

Well, I did not commit these "misfeatures" to bsd.port.mk, and ugliness
lies in the eye of the beholder. As a maintainer, I choose what is
offered to me by bsd.port.mk and decide which feature is useful enough
for me to adopt it.

To get back on topic:
It is vital that you check for WITHOUT_FOO's definedness when you
implement a default-to-on-OPTION. When doing so you can avoid the
problem we are discussing here regarding the PACKAGE_BUILDING and BATCH
cases.

Regarding WITHOUT_: I did not write that we should implement a WITHOUT_
option for every WITH_ knob out there. I am only writing about what
needs to be keept in mind _when_ one chooses to adopt OPTIONS. That some
ports already implement WITHOUT_ knobs is a matter you should discuss
with the respective maintainers, not with me.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040313160450.GA3436>