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

[Bryan Blackburn]

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

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

Bryan