MacPorts should warn of old Xcode versions

[ryandesign (Ryan Carsten Schmidt)]

We ​have the problem that from time to time, although we say in InstallingMacPorts that people must install the latest Xcode, they don't, and they end up using an older Xcode. Then they run into weird problems that we waste time investigating.

This happened recently in #12219 where someone couldn't install gcc42, and ​on the mailing list someone reported being unable to install wine. Both issues were resolved by installing Xcode 2.4.1.

MacPorts should catch this before it ever gets to Trac or the mailing list. It should either print a warning when the Xcode version is known to be outdated, or it should refuse to proceed altogether until it's updated. Landon ​objected to the latter saying users will be put off by such a large download, but Blair ​countered that developer time is valuable and we shouldn't waste it trying to re-solve problems that we already know are solved by upgrading Xcode.

We know at this point that Xcode 1.5 and 2.4.1 are fine for Mac OS X 10.3.9 and 10.4.10, respectively, so any Xcode versions earlier than those should trigger the new behavior. Alternately, Blair says Fink contains code that identifies specific bad versions of gcc, which we could look at doing too.

[afb@…]

Added variables $XCODE_VERSION and $MACOSX_VERSION in r30308.

[ryandesign (Ryan Carsten Schmidt)]

You've made these changes in the configure script. But doesn't that mean that the OS and Xcode versions are only checked at configure time? That doesn't seem like a great solution to this problem, considering that the user might upgrade Xcode or the OS after installing MacPorts, and also that the end user may not even be the one running configure; they might be installing a MacPorts binary.

[afb@…]

It's only one piece of the puzzle, now it'll warn at compile time (tarball or selfupdate). I guess you would have to reinstall after upgrading the OS, so that might be sub-optimal...

It now needs a matching runtime check when running port(1), to see that the required tools are installed and up to speed (e.g. check for "gcc" before running a build, for instance)

[jmpp@…]

It now needs a matching runtime check when running port(1), to see that the required tools are installed and up to speed (e.g. check for "gcc" before running a build, for instance)

A runtime check for an up-to-date OS and dev tools package would indeed be great. A comment and a couple of questions, though:

-) I think it would be better to implement such check at the macports1.0 level, probably as a part of the mportinit proc (so that any client initializing the API gets the safety check for free) or as a proc of its own in the macports1.0 namespace (preferable in my opinion, so that an API client is free to decide whether to check up-to-date'ness or not, as there are some clients that might not need it -- cf. PortIndex2MySQL).

-) How do you plan for such checks to work? Do the just warn or bail out? (I'd prefer the former). How do we keep an always up-to-date knowledge of what dev tools release is current at whatever moment? How would these checks tie with what's already autoconf'd?

-jmpp

[ryandesign (Ryan Carsten Schmidt)]

We don't need an always up-to-date knowledge of dev tool releases; we just need to make sure we warn about known-bad versions. Xcode 2.4.1, for example, worked great, while Xcode 2.2 caused a lot of problems. So long as a warning is issued when Xcode 2.2 is present, I'm happy.

If in the future we get lots of bug reports about, say, Xcode 3 on Leopard, and Xcode 3.0.1 is released to fix the problems, we can then insert new checks and release a new version of MacPorts.

[afb@…]

Replying to ryandesign@macports.org:

If in the future we get lots of bug reports about, say, Xcode 3 on Leopard, and Xcode 3.0.1 is released to fix the problems, we can then insert new checks and release a new version of MacPorts.

Considering the amount of reports for GTK+ on Leopard, due to the broken "extern inline" implementation of Xcode 3.0, I would say that this has already happened. Probably will happen with 4.0 too...

[afb@…]

Replying to ryandesign@macports.org:

Xcode 2.4.1, for example, worked great, while Xcode 2.2 caused a lot of problems. So long as a warning is issued when Xcode 2.2 is present, I'm happy.

Xcode 2.2 has worked OK for me, as long as not trying to compile for x86_64. Xcode 2.0, on the other hand, crashed on a daily basis. Thus there is varying warning degreees betwen those two...

[ryandesign (Ryan Carsten Schmidt)]

A runtime Xcode version check would have helped resolve #16213 much quicker.

[afb@…]

So maybe "selfupdate" should start ​softwareupdate(8) for Mac OS X and whatever ​old WebObjects app that Xcode is using for updates these days. :-) Or at least whine a little when using outdated versions, like configure does at the moment.

[afb@…]

Here's an addition to "port platform" that adds xcode_version and macosx_version, using the same line noise that the configure addition did. You can use it for other purposes, but this makes the command output something like:

Platform: darwin 8 i386
Mac OS X: 10.4.11
Xcode: 2.4.1

[wiml@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #20389.

[jmroot (Joshua Root)]

r66771