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
[EMAIL PROTECTED]
"The rules are simple: The ball is round. The game lasts 90 minutes.
All the
rest is just philosophy."
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
