Proposal: variants naming conventions
Emmanuel Hainry
ehainry at free.fr
Tue Feb 13 01:31:43 PST 2007
> I have noticed that most variants add or delete a configure flag
in the form of --enable-*/--disable-*/--with-*/--without-* and maybe
add or delete a related dependency.
:>
:> Therefore, I propose that all variants should fit the following
forms:
:>
:> {en|dis}able_package: If a ported software package has optional
compile-time features, the user can give configure command line
options to specify whether to compile them. The options have one of
these forms:
:> --enable-feature
:> --disable-feature
:> (Note that this is slightly different then how configure scripts
work[1]).
:>
:> with[out]_package: When a port requires, or can optionally use,
other ports that can be or already are installed. The user can give
configure command line options to specify which such external
software to use. A port can be written with options have one of these
forms:
:> +with_package
:> +without_package
:> (Note that this is slightly different then how configure scripts
work[2]).
:>
:> (Most configure scripts allow these options to passed with further
information in the form of --option=arg where a reasonable default is
set if =arg is not specified. port can't handle that, so =arg is not
allowed in variant names and this proposal does not contemplate
changing that)
:>
:> Changing this variant structure has, I believe, the following
benefits:
:>
:> 1) Adding the verb enable/disable/use/with/without makes the
variant more meaningful to users. I know there have been comments on
the mailing list about the inability to comment on variants such that
'port info' is capable of explaining what each variant does. The verb
will help address those complaints.
:>
:> 2) There are currently variants no-*, no_*, and no* These are
inconsistent and do not tell me (the user) if I am disabling a
feature (that some other port may depend on) or simply building the
port without using some other package.
:>
:> 3) Negative variants are confusing. with_*/without_* or enable_*/
disable_* is more readable than +*/-* as an indicator of what is
going on.
:>
:> References:
:> [1] GNU Autoconf Manual Section 12.2: Choosing Package Options,
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/
autoconf.html#SEC131
:> [2] GNU Autoconf Manual Section 12.1: Working With External
Software, http://www.gnu.org/software/autoconf/manual/autoconf-2.57/
html_mono/autoconf.html#SEC130
:>
So, if I understand correctly, you want to get rid of negative
variants (they do not get upgraded correctly) and not use the 'no'
prefix for it is not always used the same way. In order to do that,
you propose to stick to the convention of configure...
Let me point a few things:
1) not all programs use configure, and those that do do not always
use the autoconf standard.
2) as already pointed, some variants are not related to options in
the configure but to which tools to use (choosing between gnu or bsd,
choosing between the plethora of postgresql or the numerous mysql)
3) the +without_bidule does not feel logical to me: + is for adding
something, without to tell that this addition is negative...
4) configure is generally a mess (to me): I have never well
understood why with more that enable or the contrary.
5) longer variants names increases the probability of typos when
trying to install a port (and there is no automatic completion of
variants)
as an example, at the moment, I have vim installed with variants
+aqua +huge +ncurses +perl +python -ruby
(I know the -ruby is unneeded)
With this convention, it would be
+enable_gui_carbon +with_features_huge +with_ncurses
+enabel_perlinterp +enabel_pythoninterp +disable_rubyinterp
Last point, you want to make default variants more widely used.
default variants are a good mechanism, but they are not easy to
grasp: I have installed lftp +ssl -tls. The only way I had to
understand why port was insistng on building gnutls even when I tried
'port install lftp +ssl' and I saw in the portfile that ssl was
conflicting with tls was to do a 'port cat lftp | grep tls'. the
feature request here would be that
1. port info lists the default variants
2. port info port +variant takes variant into account to list the
variant to be installed and also the dependencies.
Emmanuel
More information about the macports-dev
mailing list