From: Christopher Key on
At present, the interaction between portconf and port options is
somewhat confusing. Firstly, the output of make showconfig and the
defaults displayed by make config are unaffected by anything set in
ports.conf. Secondly, its quite easy to unexpectedly end up having both
WITH_XXX and WITHOUT_XXX defined.

Consider devel/binutils:

#v+
# cd /usr/ports/devel/binutils
# make rmconfig
# make showconfig
===> The following configuration options are available for
binutils-2.20.1_3:
NLS=off (default) "Enable National Language Support"
===> Use 'make config' to modify these settings
# make -V WITH_NLS

# make -V WITHOUT_NLS
true
#v-

i.e. one option defaulting to off. We can switch it on with ports.conf:

#v+
# make -DWITH_NLS -VWITH_NLS
1
# make -DWITH_NLS -VWITHOUT_NLS

#v-

however, if options get set then things get confusing:

#v+
# make config
# make showconfig
===> The following configuration options are available for
binutils-2.20.1_3:
NLS=off "Enable National Language Support"
===> Use 'make config' to modify these settings
# make -V WITH_NLS

# make -V WITHOUT_NLS
true
# make -DWITH_NLS -VWITH_NLS
1
# make -DWITH_NLS -VWITHOUT_NLS
true
#v-

Just by accepting the defaults, we've suddenly got both WITH_NLS and
WITHOUT_NLS defined. In this case, the port checks for WITH_NLS, and
the build will be unaffected. In general, the port must check for
WITH_XXX if the default option value is off (and for WITHOUT_XXX if the
default value is on) in order to avoid the build changing as a result of
accepting the default configuration presented by make config. This
seems rather fragile, and is clearly susceptible to problems should the
default option values get changed.


The attached patch reworks the options framework slightly to try resolve
these two problems.

When a port is being built, each option defined in OPTIONS can be on or
off, and exactly one of WITH_XXX and WITHOUT_XXX will be defined after
including bsd.port.options.mk.

There are three locations from which an option can take its value: (in
decreasing order of priority)
1) /var/db/ports/*/options
2) ports.conf, make.conf and command line arguments - for now termed
environment, although a more descriptive term is desired.
3) default values from OPTIONS

When make config is run, the values displayed will be the values of the
options seen by the port when building. Typically, this would means
that when make config is first run, the values presented would be the
defaults (but would reflect anything set in ports.conf too). Subsequent
runs would then show the values saved by the last invocation of make config.

When make showconfig, the options displayed will again be the values
seen by the port when building. It also displays the location from
which the option value came from (i.e. config, environment or default).


As both /var/db/ports/*/options and ports.conf etc are stored as lists
of WITH_XXX and WITHOUT_XXX variables, it is possible for both WITH_XXX
and WITHOUT_XXX to be defined simultaneously in one location. If both
are defined in one location, then WITHOUT_XXX takes priority. If both
are defined, but only in different locations, the the first location on
the list takes priority.

For example, if /var/db/port/*/options had WITH_XXX set and ports.conf
had WITHOUT_XXX set, then the option would be on (and only WITH_XXX
would be defined after bsd.port.options.mk), because .../options takes
priority. However, if nothing was set in .../options, and ports.conf
set both WITH_XXX and WITHOUT_XXX then the option would be off (and only
WITHOUT_XXX would be defined after bsd.port.option.mk) because
WITHOUT_XXX takes priority.


Feedback would be very much appreciated.


Kind regards,

Christopher Key

 | 
Pages: 1
Prev: security/hydra and www/hydra
Next: gdc 0.24_6