ryandesign at macports.org
Wed Jul 22 19:59:00 PDT 2009
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
> 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
> I'm not aware of much that needs to know where it is located, since
> *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
> 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.
More information about the macports-dev