MacPorts wants to install apple-gcc42 on 10.6 all of a sudden?

[Clemens Lang]

On Mon, Apr 22, 2013 at 02:35:45PM +0200, "René J.V. Bertin" wrote:
> The culprit port is ffmpeg in its universal variant.

Yes, see this part from the ffmpeg Portfile:

if {[lsearch [get_canonical_archs] i386] != -1} {
    # clang-3.1 hits https://trac.macports.org/ticket/30137 (<rdar://problem/11542429>)
    # clang-139 hits https://trac.macports.org/ticket/38141
    compiler.blacklist-append {clang < 422.1.7} macports-clang-3.1

    # https://trac.macports.org/ticket/37802
    compiler.blacklist-append llvm-gcc-4.2 macports-llvm-gcc-4.2
}

The port specifically blacklists clang and llvm-gcc and the next in the
fallback list seems to be apple-gcc, which Xcode 4.2 apparently doesn't
have, which causes the Portfile to add a dependency on MacPorts' version
of it.

> Indeed. In the end I stumbled on a page that mentioned xcode-select, a
> utility I had of course never used as I'd never had multiple Xcode
> versions installed. I used it to reset the default IDE back to Xcode
> 3.x (appropriate in my case) and my issues went away.

While it is uncommon to have multiple Xcode versions I guess if you have
a patch to fix this we'd be happy to apply it.

> I started reading that page but stopped when it became apparent I
> wasn't going to find a direct answer.

The second and third paragraph in "The problem with the default
compiler" IMO has a pretty direct answer to why MacPorts doesn't do
this.

> I'll have another look, but I won't be convinced easily that there
> ought NOT be a mechanism to specify the compiler used internally
> and/or the default compile time options to use! ;)

There is a way to do this in macports.conf, but it's entirely
unsupported for good reasons and also not documented. The property IIRC
is called "default_compilers", but I couldn't find a quick reference to
how it works, so you'll have to dig in yourself if you want to use it.

> I beg to disagree :) I did exactly what the Xcode installer would have
> done had I installed in the default location, i.e. change a symlink.

While that is true, you only did _part_ of what the Xcode installer
would have done. MacPorts checks the Xcode version and assumes
/usr/bin/clang matches the Xcode version you installed. The whole point
of not modifying this is that third-party software can rely on it. You
wouldn't replace your /usr/bin/tar with gnutar either (because it would
cause random breakage in other scripts depending on /usr/bin/tar being
the BSD version on OS X).

Sure, the risk is lower when just updating to a newer version of the
same software, but it's still wrong, especially given that there are
better alternatives to change the compiler.

> > Clang is always preferred, if available. Apple GCC 4.2 is dead software.
> Maybe dead, but it's still the default compiler on 10.6 systems
> without Xcode 4. Given how short-lived Xcode 4.2 for 10.6 was, I'm
> tempted to suggest to stick to gcc-4.2 on that OS version.

And that's what MacPorts does, if you have Xcode 3.x installed and
selected. Would you suggest to still use gcc-4.2 when having 4.2
installed? Does 4.2 even ship gcc-4.2?

Btw, can you update
  http://trac.macports.org/wiki/XcodeVersionInfo
with this info?

> Is there a way to test-build a port without messing up one's
> installation tree? I guess bugs on 10.6 are probably not of the
> highest priority for you and I need a working installation ...

You can always run a different command instead of install so it doesn't
actually install the port (which would mess with what you have). E.g., I
usually do this when testing port updates:
  sudo port -v destroot <portname>
You can skip <portname> if you're in $(port dir <portname>). If you want
to specify further flags, like configure.compiler, you can do
  sudo port -v destroot <portname> configure.compiler=gcc-4.2.
When skipping <portname> because you're in the ports directory, you
probably have to replace it with "--" or "current" to prevent the latter
argument to be used as portname.

> Indeed. I'm sure there must be a way to set configure.compiler on a
> permanent basis O:-) (I even saw a patch, but it wasn't evident to me
> it's included in the default installation.)

As said, if there is, this is unsupported. You should instead file bugs
for the ports that break with clang so they can have clang or broken
versions of it selectively blacklisted.

-- 
Clemens Lang