OPTIONS

[b. f.]

David O'Brien wrote:
> On Sun, Sep 19, 2010 at 10:24:59AM +0200, David DEMELIER wrote:
> > What is "sufficiently clean" ? I wonder what is not clean in the
> > options framework, so please tell me then we still can clean it?
>
> When the Ports Collection was invented, ports maintainers were to
> choose a reasonable set of configuration for the FreeBSD community
> and have the port build that way.
>
> Today we have ports that seem to expose every single option to GNU
> configure and giving the user a puzzling choice of too many things.
> Often the explanations are nothing more than restating the option
> name and the user is left wondering what is X?  What does Y mean?
> How do I know if I really want Z or not?  Why is threading so often
> an OPTION and not just the default?  Why do I have to go read the
> packages README and INSTALLING to figure out the caveats of say
> enabling threading?  Or what the other list of things are and their
> caveats?

If you mean that some of the defaults are inconsistent, and could be
changed; and that succinct comments could be added in some places to
save time for the user, then I agree with you.  But if you think that
comments could obviate the need for learning about the software; or
that the solution is to do away with OPTIONS altogether, and hard-code
everything, I don't. You are a very experienced programmer, and you
can appreciate that there is a lot of software out there that works in
a lot of different ways. Also, there are a lot of users with different
needs.  To take your example, it may be that threading may be disabled
for one port, and enabled for another, because of some inconsequential
decision by a port maintainer. But it may also be because that port
doesn't implement threading properly for some FreeBSD platforms.  Or
because enabling it brings benefits for some users, but disadvantages
for others.  We may be able to clean up some things, but we can't make
the situation simpler than it is.

> 1. One should not have to deal with the OPTIONS dialog just to
> 'make extract' if one wants to check the license or otherwise
> investigate a port before deciding to install it.

That may be annoying, but some OPTIONS affect what is fetched and
extracted, and how, so there isn't an easy way around this.  If you
just wanted to examine the default distfiles, you could set BATCH.
The new license framework may help in the other case, after more
LICENSE entries are added to ports.

> 2. With the way OPTIONS handling is done, there isn't a way for me
> to query if I built with the defaults or not.
> Thus leading to every port I manually install looking like it was
> customized just because /var/db/ports/${PORTNAME} exists.  Thus
> implying I can no longer install the pre-build package.

This is partly an administrative issue, and I don't think that it can
be dealt with entirely within Ports. Even if we changed the
OPTIONSFILE handling to: (a) add a PORTS_DBDIR cookie, or an
OPTIONSFILE entry, to indicate if an OPTIONSFILE corresponded to the
default OPTIONS ; and (b) include all knobs that may affect the port
build, and not just those now in OPTIONS -- both of which would add
some complexity, and another potential source of error -- the
information in PORTS_DBDIR may not correspond to the packages that are
actually installed. Are you suggesting that all knobs used to build a
package should be recorded in the package, and hence in PKG_DBDIR?
That might be useful, although not easy to implement for knobs that
weren't in OPTIONS.  However, it seems to me that this kind of thing
is best handled by updating tools, like pkg-mgmt/portupgrade[-devel],
which has the per-port USE_PKGS[_ONLY] settings in pkgtool.conf.

> 3. OPTIONS are limited to only checkbox YES/NO settings.
> Why can I not set PREFIX thru the OPTIONS framework and have it come
> from /var/db/ports/${PORTNAME}/options on the 2nd and later builds?
> Even the boolean NOPORTDOCS isn't available thru OPTIONS.
> Thus it is an inconsistent way to configure a port.
>
> 4. When I build misc/mc-light and have "WITHOUT_NLS=yes" in
> /etc/make.conf, why does the OPTIONS dialog offer me
> "[X] NLS Enable gettext support" instead of defaulting the
> dialog to unchecked?

You can set those knobs via the command line, or via Makefile.{inc,
${ARCH}*, ${OPSYS}, local}, or via make.conf, where you can limit the
scope based on the .CURDIR, etc.  Although we do have a problem, as
you note in (4), with knobs that are OPTIONS, but are defined
somewhere other than OPTIONSFILE. I hadn't seen:

http://docs.freebsd.org/cgi/mid.cgi?4C476F69.1060200

until swell.k pointed it out (thanks).  I think that it does some good
things, but it does have some problems:

--I don't think the priority is right: the "environment" settings
ought to override the PORTS_DBDIR entries. This is because they will
do so anyway in some circumstances (because of recursion, or the use
of make -e/-E, or because you can't .undef some "environment"
variables), but also because users may want to perform a test build
with knobs defined in the "environment", without having to alter their
settings in PORTS_DBDIR.

--The parsing of the config files needs to be changed, so that
_OPTION_SRC_${OPT} isn't set to "config" when it should be
"environment" (see above). Also, the entries in OPTIONSFILE.local
ought to override anything in OPTIONSFILE, without regard to
precedence of WITHOUT_*.

--There needs to be a final sanity-check, that fails with an
appropriate error message if both WITH_* and WITHOUT_* are defined,
because the .undefs are not sufficient to guarantee mutual
exclusivity.

> 5. One cannot opt-out of OPTIONS.
> WITHOUT_OPTIONS does not work to just get the defaults while skipping
> the OPTIONS dialog.  Note, setting BATCH does a lot more than just
> make OPTIONS non-interactive (for some ports it stops other
> non-OPTIONS interaction with the user that one should see).  Thus
> there is no way to get an uninterrupted default build of something.

We could add a DEFAULT_OPTIONS knob, that used default values without
querying the user or overwriting an existing OPTIONSFILE.

> 6. One cannot opt-in/opt-out on a per-port basis.
> WITH[OUT]_${PORTNAME}_OPTIONS and ${PORTNAME}_WITH[OUT]_OPTIONS
> should be supported to control the OPTIONS dialog just when
> building ${PORTNAME}.

If you have (5), you can opt-in/opt-out, just as you can set knobs, on
a per-port basis.  It seems to me that little is gained, but something
is lost, by defining and parsing many per-port variables.

> 7. Setting ${PORTNAME}_WITH[OUT]_<SOME_OPTION> (or
> WITH[OUT]_${PORTNAME}_<SOME_OPTION>) should set
> WITH[OUT]_<SOME_OPTION> just when building ${PORTNAME}.
> So that folks who don't want to be interrupted with OPTIONS every
> time there is an update to the list can hardcode their choices in
> /etc/make.conf.

Again, I wouldn't want to have to define and parse scores of such
variables. You mean that, if a DEFAULT_OPTIONS knob were implemented
as in (5), you would want to use default options for any new options,
but a select set of pre-defined values for the others?  A reasonable
implementation of DEFAULT_OPTIONS and a solution to the problem of (4)
would allow you to do this as above, with the knobs, or via
OPTIONSFILE.local.

> 8. OPTIONS make a mess in the typescript file from
> 'script typescript make', and the choices are totally unreadable vs.
> 'script typescript make -DWITH_FOO -WITHOUT_BAR'.

We could print the OPTIONS settings used during a build, by default.

b.