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