64-bit versions of some ports

[Emil Lundberg]

11 feb 2008 kl. 22.39 skrev Ryan Schmidt:

>
> On Feb 11, 2008, at 06:23, Emil Lundberg wrote:
>
>>>> From the previous discussion, I remember that we (or rather mww)
>>>> started by changing the +universal variant to build all 4  
>>>> versions (2
>>>> architectures each of 32-bit and 64-bit) but this was problematic
>>>> because many ports failed to build out of the box as 64-bit, and  
>>>> there
>>>> was no clear upgrade path for those who already had 2-architecture
>>>> universal variants installed, and it was said that 64-bit  
>>>> versions of
>>>> most ports don't make sense anyway (aren't faster, or possibly are
>>>> even slower). But it seems like we want to be able to do this for
>>>> selected ports.
>>>
>>> Most of the ports that failed were using Carbon, or otherwise old...
>>> (old Carbon GUI does not support 64-bit, only Cocoa GUI does that)
>>
>> Thanks for revisiting this. There is a real need to be able to  
>> compile, by default, for the native architecture of your machine.  
>> There is also a real need to preseve backwards compatibility. A  
>> modest proposal (based on posts and discussions old and new) that  
>> might please everyone:
>>
>> * Keep the "universal" variant for building architecture-fat  
>> binaries (only).
>> * Add a new "fat" variant for building bit-fat binaries (only).
>> * Activate the "fat" variant by default on all library-class ports.
>
> What are "library-class ports"? What I mean is: what criteria would  
> you use (what portfile variables, for example) to classify a port  
> as a library-class port?

A good question indeed; I was hoping you guys could answer that! :-)

I think it would need to be determined by the maintainer of the  
individual port. Many ports are both applications in themselves but  
also libraries (R, mysql, openssl), so the line is not so clear-cut.  
My view is that _any_ port that builds shared libraries should  
(ultimately) compile as bit-fat by default on 64-bit (at least on  
intel, ppc folks may beg to differ). Perhaps a category ("library",  
"64bit") could be added to signify this? Or a platform, but that just  
sounds wrong.

But, to get things going, how about simply adding a standard variant  
"64bit" that, just like "universal", is always available (right?).  
The daring could then add it to variants.conf, and those who (like  
myself) take an active interest in 64-bit could try ports out, file  
bug reports etc. afb had a suggestion on how to handle this in a  
decently port-neutral I believe.

Those on 32-bit machines, etc, would obviously not bother using it  
unless they wanted to build fat binaries for some reason.

Downside is that a variant that might not be tested appears as an  
option. So how is universal handled? Is it always expected to work if  
it is available? Can it be disabled for the ports that for some  
reason don't support it? Can one specify "-universal" for a single  
port at build time?


>> * Add an config option to set the default bit-ness ("always 32- 
>> bit" or "native") for all builds.
>>
>> Some of it may well be in there already; I haven't been able to  
>> locate it in the docs though, e.g. where does "universal_archs"  
>> apply...?
>>
>>
>>> I reverted +universal back to meaning "10.4u SDK for ppc/i386 arch",
>>> and then made them into parameters for overriding locally if  
>>> desired.
>>
>> So is it possible, using the current MacPorts 1.6.0, to build bit- 
>> fat/quad-fat binaries, and if so, how is this accomplished (feel  
>> free to bring this onto the users-list)?
>
> That comment applied to trunk only. 1.6.0 does not have the  
> universal_archs variable, and has always built only the two 32-bit  
> architectures. MacPorts in trunk has universal_archs, which was for  
> a time set to all 4 architectures, but that didn't work well and  
> then was changed to use only the 2 again. Someone using MacPorts  
> trunk could set universal_archs to a different set of architectures  
> to include in a universal build, but I would not expect any  
> portfile author to have tested with anything other than the default  
> "ppc i386" architecture set.

Right. I do feel, however, that architecture and bit-ness need to be  
handled separately. Architechture-fat binaries, I presume, are built  
to increase usability on several machines (for binary distribution in  
some form), while bit-fat binaries are commonly built for use on the  
_same_ machine, e.g. to provide both 32- and 64-bit version of  
libraries.

I can try trunk on a demo setup, using universal_arch="ppc ppc64".  
How, exactly, do I use this variable?


/Emil