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@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."