[54124] trunk/dports/graphics/tiff/Portfile

[Ryan Schmidt]

On Jul 24, 2009, at 01:01, Bryan Blackburn wrote:

> Sorry, I was a bit imprecise; the SDK stuff is for targetting a  
> specific
> version of Mac OS X, which MacPorts definitely can't do currently.   
> So,
> other than 10.4/PPC, why are we referencing the SDKs at all?   
> Universal
> (i386+ppc, i386+x86_64, etc) don't need the SDKs to do that (again,  
> other
> than 10.4/PPC).

With MacPorts 1.7.1, a user can specify an alternate Mac OS X  
deployment target and SDK in macports.conf. Admittedly a lot of  
software didn't like this, and since this feature has already been  
removed from trunk I won't belabor it.


>> While I'm not happy with our universal support yet, removing it would
>> limit a user to choosing either all 32-bit or all 64-bit software.
>
> We currently have the issue where all dependencies must be built  
> +universal
> to make a port itself work with +universal, so aren't we already  
> there?  And
> if someone builds +universal with universal_archs set to 'i386 ppc'  
> and
> later changes it to 'i386 x86_64', what happens?
>
>> Since build_arch was only just added to MacPorts trunk, and Snow
>> Leopard, which is the first version to build 64-bit by default, is
>> not released yet, I doubt the majority of ports have been tested for
>> 64-bit compatibility, so I bet we have some ports that don't build
>> 64-bit. (wine springs to mind, last time I checked.) Many people have
>> so far been using universal as a way to get 64-bit, setting
>> universal_archs to i386 x86_64. For ports that cannot build 64-bit,
>> you simply don't install it universal, and it builds 32-bit, using
>> the 32-bit part of its dependencies. If we remove universal, you
>> would either choose 64-bit software and then not use those 32-bit-
>> only ports at all (since the dependencies would be 64-bit only), or
>> you use only 32-bit software. That seems worse than what we have now,
>> which lets the user use 64-bit for the ports where it's possible and
>> 32-bit for those where it's not.
>
> Again, except for dependencies.  Universal is great when you  
> distribute
> binaries, but of course MacPorts doesn't do that currently.  I  
> realize one
> nicety to universal is that people can build on a fast (Intel)  
> machine and
> then share the result with a slower (G4) machine to avoid slow  
> build times.
> Outside of that, since we still build from source otherwise, what  
> are the
> advantages?

My above example was meant to illustrate the problems of a single  
user running software on a single Mac. Let me give a concrete  
example. Imagine a user wants to install a 64-bit version of mysql5  
to allow it to use more than 4G of RAM, but also wants to install  
wine. Wine cannot be built 64-bit (last I checked). Both ports depend  
on zlib. With today's universal support, the user can build an i386/ 
x86_64 universal version of zlib. He can then build mysql5 64-bit  
only, and it will use the 64-bit parts of zlib, and he can build wine  
32-bit only, and it will use the 32-bit parts of zlib. If you remove  
universal support from MacPorts, the user must either not use wine at  
all, or must live with a 32-bit mysql5, or must manage two MacPorts  
prefixes, one for 32-bit and one for 64-bit software.


> The disadvantages are all the various tickets for universal support  
> (57
> currently open with 'universal' in the summary, 248 total), the  
> ongoing
> changes to try and make it work, the muniversal port group, etc.   
> Doing it
> right with all this baggage just complicates an already difficult  
> task for
> too few of us working on base, so do we want to continue this  
> route, or stop
> and try to actually find a better, cleaner, maintainable way?
>
> Maybe I'm just in the minority here and everyone else thinks it's  
> fine, so
> perhaps I'm just missing something?

No, I fully agree, we have some problems. I'm in favor of finding a  
better, cleaner, maintainable way. Do we have any idea what that  
might be?

I still promote the idea that MacPorts should build for a single  
arch. We now even have a means of specifying that arch with the  
build_arch variable. Our hypothetical Intel build server would build  
once for i386, then build again separately for x86_64. If we have a  
PowerPC build server, it would build once for ppc, then build again  
separately for ppc64. All these parts would be shuffled to one  
machine, which would merge them together and produce a universal  
binary that our hypothetical binary support would download and  
install on user machines.

Clearly this relies on a lot of parts that aren't built yet. And it  
also assumes that a bunch of separate installs can be merged into a  
single one without further input. We already know this is isn't so;  
we will need a way for ports to indicate what to do with non-binary  
files which are different. That's what a bunch of the code in  
muniversal is there for.

Ports still need a way to specify what architectures they can build  
for, since not all ports can build for all architectures. muniversal  
introduced a way to do that but it's not integrated with MacPorts  
base and isn't used when not building universal.

I feel like I'm about to go off on a tangent about binaries so I'll  
stop here and wait to hear what other ideas there are about new  
universal support, or more thoughts on whether or not universal  
support is still necessary in MacPorts now.