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

[Bryan Blackburn]

On Wed, Jul 22, 2009 at 09:59:00PM -0500, Ryan Schmidt said:
> On Jul 22, 2009, at 16:45, Bryan Blackburn wrote:
[...]
> >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?

Good question, I think the initial stuff was partly just a way of avoiding
having more hardcoded paths, with the potential to more easily do something
more intelligent with it in the future.

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

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

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

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?

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?

Bryan