Universal issues

[Rainer Müller]

Ryan Schmidt wrote:
>>    3) Builds always universal (because the build system does that)
> 
> I think we should strive not to have this situation... if the port  
> builds universal by default, an effort should be made to change the  
> build so that it builds non-universal by default, and universal only  
> when the universal variant is chosen. I know Anthony did this for  
> many ports. For my ports that build universal by default I did not do  
> this (sleepwatcher, and I just found out adtpro), and I should go  
> back and fix this.

Okay, this is of course also a possible solution. But it means more work 
to patch the build system of these ports not to build universal.

>>> http://lists.macosforge.org/pipermail/macports-dev/2007-June/ 
>>> 001868.html
>> I agree that we need the lipo strategy and we already have a merge  
>> proc
>> which is able to lipo to independent builds together. Your proposed
>> universal.method sounds fine to me.
> 
> Then later, I would want to rename "livecheck.check" to  
> "livecheck.method" for consistency.

I agree totally that livecheck.check should be changed. But other phases 
use .type (fetch.type, build.type, archive.type ...) and not .method. We 
should use livecheck.type and universal.type for consistency.

> "supported_archs" may be too wordy... maybe "archs" is enough. After  
> all, we have "platforms", not "supported_platforms".

Agreed.

>> I was also thinking some time ago about extending the platforms
>> statement to include version information. Something like:
>> platforms    {darwin >=8}
> 
> Maybe.
> 
> For now I'm making use of ${os.major} inside a "platform macosx"  
> block. Quite often when I need to employ a patch, the criteria is  
> "Mac OS X 10.x and earlier" and not merely "Mac OS X 10.x exactly".

Which does not record this information in the variants. Ideally this 
would be multiple platform blocks or an addition to the syntax, see below.

 >[...]
>> It would be a possibility to add the architectures to the variants  
>> as we
>> use it for the platforms.
> 
> I like it. Always include the architectures in the selected variants.  
> I'd go one further and say always include the OS -- always include  
> darwin_8 on Tiger, for example. Recording the arch and OS makes it  
> clear that users who upgrade from one OS to the next or from one arch  
> to another should reinstall. It also gets closer to something I've  
> wanted: a string that uniquely identifies what was installed. Port  
> name + version + variants (now including OS and archs) should do it.  
> I'm thinking about if and when we have binary packages. With this  
> enhancement, we would no longer have the current situation that e.g.  
> "cairo at 1.6.4_1+macosx" built on Panther is a different complement of  
> software than it is on Tiger.

Currently, we include this only if the port has some specific platform 
variant for the target platform. But what should we do on universal 
builds? Include +universal+darwin_8+darwin_9+i386+ppc?

cairo is using a check for the OS version inside the variant. We should 
have  platform macosx 10.3 {}  instead (as we have for darwin). But I am 
not sure if this is already possible.

If this is needed for multiple versions it needs to be copied. Again, 
something like  platform macosx <=10.3 {}  would be helpful.

 >[...]
> Someone suggested in another thread we should store the Xcode version  
> and the complete OS version. Why not. Let's store more info now, then  
> if we need it later it'll already be there.
> 
> Maybe we don't want to store all this in the variants though. Maybe  
> we can invent a new place to store this information.

We could store it in the receipt in registry1.0. But maybe we should 
delay such additions to registry2.0? I hope it will be a lot easier with 
the sqlite3 backend to add new variables.

At least there should be a difference between normal variants and 
platform variants.

> [...]
> My script actually runs "lipo -info" (not "file") on each file to get  
> the archs. Possibly the speed of identifying files can be improved by  
> integrating the minimal required functionality into MacPorts (in Tcl  
> or C) so that we don't have to execute a subprocess for each  
> installed file.

I don't know if the current source for lipo is available (I had a look 
in cctools, but it is not there). I don't know the Mach-O format, but we 
could add this functionality to pextlib.

Rainer