Compiler name baked into our packages

[Ryan Schmidt]

On Oct 5, 2012, at 07:03, Jeremy Lavergne wrote:

> We don't really need more than one buildbot per OS: we simply restrict what we build to the most current free version of Xcode for each OS.

That would be another good thing to do, but we don't do it currently. Our Lion buildbot has not been updated past Xcode 4.3.2. It would be great to update this Xcode, since the clang in Xcode 4.3 does not respect LIBRARY_PATH which causes various problems. My understanding is that the buildbots are one of the next things on the list in the Mac OS Forge infrastructure restructuring, at which time perhaps Xcode 4.5.1 can be installed.



On Oct 5, 2012, at 08:38, Jeremy Lavergne wrote:

> Xcode 4.2 isn't available for Snow Leopard except for paid accounts--it really shouldn't even be considered.

It should be considered to the extent that users who have installed it should not encounter the problems that they are encountering, as in for example the bug report I referenced in the first message.



On Oct 5, 2012, at 10:20, Joshua Root wrote:

> Anything that tries to use a nonexistent compiler is not respecting
> configure.cc and friends. Fix that problem.

Ok. To help us identify ports thus affected, we could modify the ports that bake the compiler name into themselves (perlX.X, qt4-mac, pythonXX, etc.) to replace the baked-in compiler name with /usr/bin/false, to ensure that the thus affected ports fail to build. This might be disruptive to users so perhaps a few maintainers could try this change locally on their systems. I'll see if I can try it out myself.



On Oct 5, 2012, at 10:43, Blair Zajac wrote:

> We could have a gcc in our bin that is a shell script that calls the real gcc on the system and we compile with that gcc.  This gcc could pick the correct compiler for the port indicated by an environmental variable.

We've gotten this far without resorting to a wrapper script for the compiler... I'm not sure we want to open that can of worms now. I worry that it will cause more problems than it solves.

Presumably we could test whether it causes any problems by 1) making /opt/local/bin/gcc a symlink to the right compiler, or a script that runs the right compiler; and 2) setting... *something* to macports-gcc in macports.conf; I thought we had a setting for that since MacPorts 2.1 but I can't find it.


On Oct 5, 2012, at 11:12, Bradley Giesbrecht wrote:

> I believe there were machines shipped with Xcode 4.1 and possibly 4.2 on the install cd's.

I didn't know any Snow Leopard machine shipped with Xcode 4... but it makes sense, for 4.0 at least. Xcode 4.0 was released March 2011, and Lion and Xcode 4.1 weren't released until July 2011.

I would expect any machines shipping with Xcode 4.2 were shipped with Lion, since 4.2 was released October 2011, months after they were already shipping machines with Lion.