plans for 64bit support

[Ryan Schmidt]

On Dec 18, 2007, at 23:46, Joshua Root wrote:

> Ryan Schmidt wrote:
>
>> We could introduce a new automatic variant... +universal4?
>> +universal64? People could test with this new variant and if any
>> problems are encountered it would not prevent anyone from using the
>> existing 2-way 32-bit +universal variant. I'm wary of this though...
>> I wouldn't want, say, "universal64" directives to start appearing in
>> portfiles, if we want to eventually fold +universal64 into  
>> +universal.
>
> I've been considering this, and my current thoughts are:
>
> The default should be to build 32-bit binaries on ppc64 machines,  
> since
> ppc64 code is generally slower. There should be a config file  
> option so
> those on ppc64 hardware can build everything 64-bit if they want. On
> x86_64 machines, 64-bit binaries should be the default.
>
> +universal should default to building for ppc32, x86, and x86_64. That
> will generally give the best performance everywhere.

An interesting perspective. Is there documentation backing up the  
claim that 64-bit ppc code is slower on 64-bit ppc machines than 32- 
bit ppc code?


> But then of course you need a way to specify to build for ppc64. For
> universal builds, perhaps an extra variant could be added, e.g.
> '+universal +ppc64' would build 4-way binaries. Or alternatively, a
> different universal variant like the aforementioned '+universal4'.
>
> There's also a related problem: not all ports will necessarily build
> correctly for all architectures. Switching to building everything  
> 64-bit
> right now is a gamble.

It's not a gamble; I guarantee you a largish number of ports will  
fail. Just like a largish number of ports fail to build 2-way 32-bit  
universal binaries today, which is why +universal is not the default.

> So before MacPorts starts building any 64-bit
> code by default, there would need to be an effort to make sure that as
> many ports as possible are 64-bit clean. After the switch, there would
> also need to be a portfile flag that indicates that the port is not
> 64-bit clean. Ideally the presence of that flag would simply  
> disable the
> 64-bit architectures when doing a universal build.

Our existing universal support also needs some help in this regard.  
All we currently have is a default universal variant which works for  
some ports, a "universal_variant no" flag you can add to the port to  
turn off that default variant, and of course authors can define their  
own universal variant to do something different.

There's no way to indicate that a port has been tested and works when  
built universal.

There is no way to indicate why "universal_variant no" is being used  
-- is it because the port fails to build universal? is it because the  
port does not install any binaries and therefore does not need to be  
built universal?

There is no way to indicate that the port already builts universal  
without any assistance (other than hacking it with "variant universal  
{}" and "default_variants +universal").

And finally, we don't have any way to run the configure, make and  
make install phases of a port twice, then lipo the end result  
together. This is needed for some ports, like cairo and openssl,  
which have to go to great lengths to fake this in the portfiles  
themselves.

Except for the 64-bit issue, I have brought this all up before, and  
nobody had anything to say to it...

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

I think we really need to think about how we want our universal  
support to work as a whole before we start adding little extra things  
into MacPorts.