recommended "dependencies?"

[Randall Wood]

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 <ryandesign at macports.org> 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 at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-users


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."