What's the reasoning behind using ld64 for gccXX?

[Jeremy Huddleston]

On Apr 18, 2012, at 21:42, Sean Farley wrote:

>> We ran into the same complaints when I fixed the xorg libraries in MacPorts and started updating ports to depend on them.  People started complaining that they had to build all these new ports when things were "just fine" the way they were, but in the end it was the right solution.  Tiger through Mountain Lion can all use the (mostly) identical X11 server and clients.
>> 
>> Yes, you need to take 20 more minutes to build llvm, ld64, and cctools, but guess what, it's worth it in the end.
>> 
>> If you want to build your own gcc which *DOESN'T* use MacPorts, you're free to use fink, homebrew, or just build it yourself.
> 
> So, you're the one driving people to drink? I'll have to send you my
> bar tab, then.

Huh?  If you're suggesting that I'm the one setting this policy, the answer is no.  One of the major reasons I use MacPorts instead of the alternatives is BECAUSE of this policy which has existed  well before I arrived.

> FWIW, I've managed to use my own fork of macports (which I've called
> scienceports) with no X11 being built and a binary version of gfortran
> that I've compiled for my co-workers who insist on using HPC gfortran:

Ok, why fork?  Submit patches.  If certain ports don't need X11, then they should have x11 variants to allow turning it off.  File bugs, and fix bugs here rather than forking.

> https://bitbucket.org/seanfarley/scienceports
> 
> Would it be possible to get a variant +xcode or something similar to
> -x11 or +no_x11? Can't we all just get along?

no_* variants are not kosher any more.

-x11 means you don't want to use *ANY* X11.

There is absolutely no option in MacPorts to allow you to build using /usr/X11.  There was for a while during the transition, but that was removed.