Proposal: variants naming conventions

[Randall Wood]

On 11 Feb 2007, at 13:12, Yves de Champlain wrote:

>
> Le 07-02-11 à 10:25, Randall Wood a écrit :
>
>> 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

These should be +enable_feature and +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.
>
> I agree on both the usefulness of this undertaking and the logic of  
> this proposal.
>
> However, two points are less clear for me :
>
> 1- You seem to propose "use" and "add" keywords, but I don't see  
> their usefulness.  [en|dis]able and with[out] look plain perfect to  
> me, unless there is somme case I miss.

The "use" keyword was left over from a similar proposal from May  
2006. Sorry about that. It should not have been in there.

"add" keyword? I have not proposed any such thing; I merely hope my  
grammar it not that bad.

> 2- My experience is that variant names should not include "-"  
> because of the way arguments are parsed.  I always use underscore  
> "_" because of that, but if I am wrong, I would be glad to know !

I know. I would like it if that could change, although I don't see it  
changing as long as negative variants are allowed.

> Finally, shouldn't ports build most of the functionnalities by  
> default ?  Maybe it is a good time to say it again.

I think that the richest port possible should be the default port,  
however, I also am aware that say, when a port needs a database and  
that the database requirement can be solved using 1 of 9 different  
ports, that the use of variants will be almost certainly required.

There have been situations, at least in the GNOME ports, where I have  
had to turn off functionality for compatibility or reliability when  
shipping a port, and have left it optional for those who wanted it.

>
> yves
>


Randall Wood
rhwood at mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."