[33798] trunk/dports/mail

[Ryan Schmidt]

On Feb 5, 2008, at 17:21, Rainer Müller wrote:

> Simon Ruderich wrote:
>
>> On Tue, Feb 05, 2008 at 11:29:37AM -0600, Ryan Schmidt wrote:
>>
>>> Since it doesn't seem to install any compiled software, I think  
>>> it needs a "universal_variant no" bit.
>>
>> Thanks for your hint. I just added it.
>
> As this software is just a perl script and requires no extra steps  
> for other architectures shouldn't it considered to be already  
> universal?
>
> Which would be:
>   default_variants +universal
>   variant universal {}


I would say no. I would say "universal_variant no" is currently  
appropriate for software that is architecture-agnostic, like this  
perl script.


Though I've never been really happy with "universal_variant no". It's  
not a Boolean situation. See my earlier message:

http://lists.macosforge.org/pipermail/macports-dev/2007-June/001868.html

In it, I suggest that "universal_variant" should be replaced with  
"universal.method" and have several possible values. Actually I don't  
care so much if it's renamed, but I do care that we support these  
options:

"autoconf" (like "universal_variant yes" today)
"lipo" (automated multiple building and merging with lipo [1])
"none" (like "universal_variant no" today)
"implicit" (software is already universal and can't be built non- 
universal)
"unknown" (default; same as "autoconf" (if "use_configure yes") or  
"lipo" (if "use_configure no") but prints a warning that this is  
untested)

I now revise my suggestion in that "none" should be further divided  
into these two options:

"unnecessary" (port is arch-agnostic)
"impossible" (port fails when built universal)

These names may not be great; suggestions for other names for these  
options welcomed. For example "lipo" might be better called "merge".


[1] I also suggested this in an earlier message:

http://lists.macosforge.org/pipermail/macports-dev/2007-April/ 
001319.html