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

[Ryan Schmidt]

On Jul 22, 2009, at 16:45, Bryan Blackburn wrote:
> On Wed, Jul 22, 2009 at 03:41:57PM -0500, Ryan Schmidt said:
>> On Jul 21, 2009, at 21:09, Bryan Blackburn wrote:
>>> Note that the port was broken for installs of Xcode outside of /
>>> Developer, so changing without maintainer approval makes
>>> sense if that's all that's being touched.
>>
>> I had thought MacPorts had never worked with Xcode outside of /
>> Developer. Also, our current documentation does not list this as a
>> reason to allow non-maintainer updates. We should allow more non-
>> maintainer updates; I'll open a new thread about this.
>
> For the most part, all we really care about is what's in /usr so  
> Xcode's
> specific install location hasn't really matter (and of course,  
> until 2.5, it
> couldn't be easily changed anyway).  Other than the Xcode version  
> checks,
> I'm not aware of much that needs to know where it is located, since  
> the
> *nix-level tools are in /usr as well as xcodebuild.
>
>> I was thinking of the fact that developer_dir was just added to
>> trunk. I don't know what all it's used for.
>
> I believe the plan is to be able to abstract out the specific  
> location so we
> can support various locations of Xcode (which would probably be  
> good for
> anyone with multiple versions installed as well).

So are you saying we want to be able to access the *nix-level tools  
within the Xcode install location instead of within /usr?


>> I was also thinking of the universal SDKs. But in 1.7.x I suppose the
>> user can specify the path to those in macports.conf, and in trunk
>> that's been removed and the SDK is only used on Tiger PPC, which
>> doesn't need developer_dir since Xcode can't be relocated on Tiger.
>
> Note that the SDKs are technically not for universal (except as you  
> note, on
> 10.4/PPC) but are for targetting a certain OS version.  I'd really  
> like to
> see any and all use of the SDKs removed since the official MacPorts
> policy is that we don't support cross-platform development.

For some meaning of the word "support", we have been supporting the  
universal variant with i386 ppc for some time, which counts as cross- 
compiling. Admittedly it often doesn't work.

> And further to
> that, I'd also really like to see +universal removed completely  
> until it can
> be done more cleanly, since that definitely seems to be a major  
> cause of
> tickets & support issues.  Things like keeping track of actual  
> build archs
> instead of just noting +universal would be a necessity if we really  
> want it
> to work; we currently just say "you need to make sure everything is  
> built
> the same" but that'd be better done by port.
>
> Though I'm guessing we're going to need to revamp the registry  
> first in
> order to properly store these settings...

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.  
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.