Landon Fuller wrote:
On Jul 29, 2007, at 17:21, Blair Zajac wrote:
On Jul 29, 2007, at 4:11 PM, Ryan Schmidt wrote:
Here's a message from the -users list just now:
On Jul 28, 2007, at 18:39, Chris Waterson wrote:
Hey, I had the same problem. It turns out I was using an older version of Xtools (specifically, version 2.3). After upgrading to Xtools 2.4.1, things worked fine. (The specific trouble, which you can see if you get rid of the "-j2" option in the makefile, is that they've changed some of the defines in the header files that the boehm-gc needs.)
Problems caused by old Xcode versions are reported by users with some regularity. I suppose we could add something to the FAQ, but users don't always read the FAQ, and the first step of the first section of the installation guide already reads: "Download and install the latest version of Xcode Tools—do not install an older version from the OS X 10.4 install disk or some ports may fail to install."
We should not allow users to run into this problem. Can we please modify MacPorts base to issue a fatal error and refuse to do anything unless the latest Xcode (2.4.1 on 10.4.x, 1.5.x on 10.3.x) is installed? I think this would be a good idea. When new versions of Xcode are released, we can update base as needed.
+1.
Tentative -1, simply because Xcode is a massive download. Most things will build with an outdated version, I don't think it's particularly nice to force people to download a gigabyte update if they don't need and/or want to. Also, we shouldn't try to second guess people who do know what they're doing with an "unsupported" Xcode version.
I guess it's viewing who's time is more valuable. Having MacPorts people spending time wondering why things don't build properly or the person using MacPorts. I would rather put the burden on the person using MacPorts then on the MacPorts' developers. If there was a problem with a port with an older XCode version, the last thing I'm going to do as a MacPorts developer with limited time is to downgrade my XCode to figure out the problem, when the newer version is known to work. We could also do what Fink does, is report known bad versions of gcc. We can get the list of bad gcc's out of their code. If we find a bad gcc version, report it to the person running port. Regards, Blair