A while back (about 6 months ago I think), I proposed a standard for
naming variants.
As I recall, there seemed to be a consensus that I had a good idea,
but that details needed to be worked out. I (and I think a couple of
others) began using variants as I proposed, although I notice that
recently someone took one of the ports that I wrote and renamed all
the variants I had as they were "nonstandard"
Anyway, here's the proposal again, tweaked to not require any changes
in the port command:
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:
enable_*/disable_* (Enable or disable a feature that may depend on
something else that a user may or may not want installed. For
example: +enable_python or +disable_python to build a port that can
optionally use python to extend functionality)
with_*/without_* (Build with a certain port to provide a backend
service or to change some aspect of how the program works without
changing the program's functionality. For example: +with_gnome or
+without_gnome to build a port that uses gnome standard file open/
close dialogs instead of gtk file open/close dialogs)
Changing this variant structure has, I believe, the following
benefits:
1) Adding the verb enable/disable/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-* is more
readable than +*/-* as an indicator of what is going on.
Further, I would add that having +disable_rtf and +enable_rtf
variants is a good idea, and that the default_variants mechanism
should be used to determine which will apply if none are specified.
On 9 Feb 2007, at 15:30, Mark Duling wrote:
Ryan Schmidt <[EMAIL PROTECTED]> on Friday, February 9, 2007
at 9:07
AM -0800 wrote:
could one use variants to implement an abstract port? for example,
could
i write a port called abstract/tex-previewer and have different
variants
to select dependencies for aqua/TeXShop and x11/advi? perhaps an
+aqua
variant to specify that a default aqua-enabled previewer should be
used...
I don't think portfiles that don't represent concrete apps or
libraries is
a good id, and I'm not aware that this has been done before. I would
think it would create as many problems as it would solve. Not sure if
this applies here, but a port may contain variants that do nothing
in the
port - {}, but they will still select a variant of the same same when
installing a dependency. I just used this method for the new
smokeping/speedycgi ports so that when installing smokeping for
Apache 1,
speedycgi is installed linked against Apache 1 also by using the same
variant name in both portfiles. Not sure if that helps at all for
what
you want to do but I thought I'd throw it out just in case.
Mark
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
Randall Wood
[EMAIL PROTECTED]
"The rules are simple: The ball is round. The game lasts 90 minutes.
All the
rest is just philosophy."
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
