Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#11280 closed defect (fixed)

check XCode version on MacOSX, and bail out if it is 4

Reported by: dimpase Owned by: GeorgSWeber
Priority: blocker Milestone: sage-4.7
Component: build Keywords: XCode 4
Cc: drkirkby, was, jason, jdemeyer, kcrisman Merged in: sage-4.7.rc2
Authors: Dmitrii Pasechnik Reviewers: David Kirkby
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by dimpase)

Currently, XCode 4 (namely, version 4.0.1) produces a Sage executable that crashes on startup. Here we patch prereqs to guard against it. Please see http://groups.google.com/group/sage-devel/browse_thread/thread/54e9c5216ad6451f for more details.

This patch also takes care of #8566.

The patch should be applied in SAGEROOT/spkg/base, using hg import In same directory, one should place http://boxen.math.washington.edu/home/dima/patches/prereq-0.9.tar (and remove prereq-0.8.tar; prereq-0.9/ is an exact copy of prereq-0.8/, only renamed)

PS. If you want to test this in existing Sage installation, you can start ../../sage -sh in SAGEROOT/spkg/base, untar prereq-0.9.tar, and start ./prereq-0.9-install

Attachments (1)

trac_11280_xcode4unsupported.patch (35.2 KB) - added by dimpase 9 years ago.
export with --git to record file permissions

Download all attachments as: .zip

Change History (26)

comment:1 Changed 9 years ago by dimpase

  • Cc drkirkby was jason added
  • Description modified (diff)

comment:2 follow-up: Changed 9 years ago by logix

With XCode 2.4:

$ xcodebuild -version
Component versions: DevToolsCore-757.0; DevToolsSupport-733.0

so in the patch $XCODE_VERS (and $XCODE_VERS_MAJOR) end up being empty. A more reliable way to check for the version might be what Macports is doing - essentially that's

$ defaults read /Developer/Applications/Xcode.app/Contents/version CFBundleShortVersionString

which prints "2.4" for me.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 9 years ago by dimpase

Replying to logix:

With XCode 2.4:

$ xcodebuild -version
Component versions: DevToolsCore-757.0; DevToolsSupport-733.0

so in the patch $XCODE_VERS (and $XCODE_VERS_MAJOR) end up being empty. A more reliable way to check for the version might be what Macports is doing - essentially that's

$ defaults read /Developer/Applications/Xcode.app/Contents/version CFBundleShortVersionString

which prints "2.4" for me.

One can, I suppose, just do

if [ $XCODE_VERS_MAJOR = "" ]; then
   XCODE_VERS_MAJOR="2"
fi

OK, you can't build Sage with XCode 2, anyway, right? So this also should be checked and the installation should exit, isn't it?

comment:4 in reply to: ↑ 3 ; follow-ups: Changed 9 years ago by logix

Replying to dimpase:

One can, I suppose, just do

if [ $XCODE_VERS_MAJOR = "" ]; then
   XCODE_VERS_MAJOR="2"
fi

Well, technically in this case we might even be seeing XCode 1, but I suppose that that check will do in practice - at least if your check works with even the oldest XCode 3.x versions.

OK, you can't build Sage with XCode 2, anyway, right? So this also should be checked and the installation should exit, isn't it?

The last time I tried, it worked, but that was almost a year ago (Sage 4.4.3). I haven't tried since then, but I'll see if I manage to do so within the next couple of days.

comment:5 Changed 9 years ago by dimpase

  • Cc jdemeyer added

comment:6 in reply to: ↑ 4 Changed 9 years ago by dimpase

  • Status changed from new to needs_review

Replying to logix:

I updated the patch to handle cases of Xcode's major version less than 3. Please test (I tested the script as much as I could, but I don't have a very old Xcode around)

comment:7 Changed 9 years ago by dimpase

  • Cc kcrisman added

comment:8 Changed 9 years ago by jdemeyer

  • Authors set to Dmitrii Pasechnik

Doesn't break anything on OS X 10.4 PPC.

$ uname -a
Darwin moufang.ugent.be 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
$ xcodebuild -version
Component versions: DevToolsCore-762.0; DevToolsSupport-764.0

comment:9 follow-ups: Changed 9 years ago by drkirkby

  • Status changed from needs_review to needs_work

If this Xcode version checking is performed, then the version of prereq needs to be incremented to 0.9, otherwise we are going to have different code with the same version number. That means creating a new tar file (prereq-0.8.tar), and changing the TARGET at the top of prereq-0.9-install to:

TARGET=prereq-0.9

Also, I think the bit of code following:

    if [ $XCODE_VERS_MAJOR -gt 2 ]; then
        echo "You are using XCode version " $XCODE_VERS
        echo "WARNING: You are strongly advised to install Apple's latest XCode 3,"
        echo "unless you already have it. You can download this from "
        echo "http://developer.apple.com/xcode/"
    fi

should make it clear not to install Xcode 4. Although the message says to use the latest Xcode 3, someone reading it is likely to interpret that as to just upgrade.

Also, why use the -e option to sed? That's for when you want to specify the name of a script. If you put the script inline, as you have done here, the -e can be removed.

Dave

comment:10 in reply to: ↑ 9 ; follow-up: Changed 9 years ago by jdemeyer

Replying to drkirkby:

Also, why use the -e option to sed? That's for when you want to specify the name of a script. If you put the script inline, as you have done here, the -e can be removed.

Sorry Dave, you're wrong here (you are confusing with -f). -e is meant exactly for inline scripts. It is an option with one argument, namely the script to be executed. I agree that it is redundant in this situation, but the usage is correct.

comment:11 in reply to: ↑ 10 Changed 9 years ago by drkirkby

Replying to jdemeyer:

Replying to drkirkby:

Also, why use the -e option to sed? That's for when you want to specify the name of a script. If you put the script inline, as you have done here, the -e can be removed.

Sorry Dave, you're wrong here (you are confusing with -f).

Yes, I was.

-e is meant exactly for inline scripts. It is an option with one argument, namely the script to be executed. I agree that it is redundant in this situation, but the usage is correct.

Agreed, but it can still be removed. It's pointless having it.

comment:12 in reply to: ↑ 9 ; follow-up: Changed 9 years ago by drkirkby

Replying to drkirkby:

If this Xcode version checking is performed, then the version of prereq needs to be incremented to 0.9, otherwise we are going to have different code with the same version number. That means creating a new tar file (prereq-0.8.tar),

The new tar file should be prereq-0.9.tar of course and not prereq-0.8.tar as I stated.

Dave

comment:13 in reply to: ↑ 12 ; follow-up: Changed 9 years ago by dimpase

  • Status changed from needs_work to needs_info

Replying to drkirkby:

Replying to drkirkby:

If this Xcode version checking is performed, then the version of prereq needs to be incremented to 0.9, otherwise we are going to have different code with the same version number. That means creating a new tar file (prereq-0.8.tar),

The new tar file should be prereq-0.9.tar of course and not prereq-0.8.tar as I stated.

Dave

Well, I don't follow the 0.9 vs 0.8 question. I really have no idea what you are talking about, in this respect. Please explain if I need to adjust the patch.

I'll fix the point that "latest" must mean "latest, but not Xcode 4", that's easy.

Dima

comment:14 in reply to: ↑ 13 ; follow-up: Changed 9 years ago by drkirkby

Replying to dimpase:

Well, I don't follow the 0.9 vs 0.8 question. I really have no idea what you are talking about, in this respect. Please explain if I need to adjust the patch.

I'll fix the point that "latest" must mean "latest, but not Xcode 4", that's easy.

Dima

Dima,

The way Sage checks it's prerequisites is not my idea of a good way, but this is how it works:

  • There's an executable shell script $SAGE_ROOT/spkg/base/prereq-0.8-install
  • There's a tar file in $SAGE_ROOT/spkg/base/prereq-0.8.tar
  • When $SAGE_ROOT/spkg/base/prereq-0.8-install executes, it extracts the contents of $SAGE_ROOT/spkg/base/prereq-0.8.tar. That tar file has a "configure" script generated by autoconf. The "configure" script then executes and does some other tests that are not in the $SAGE_ROOT/spkg/base/prereq-0.8-install.

You are editing a script (currently prereq-0.8-install). Once edited, the version number of that script needs to be incremented, like one does whenever one makes changes to software. The most obvious name in this case would appear to be rename that script to prereq-0.9-install. (Since it under revision control, that needs to be done in Mercurial)

The top of the script has a name hard-coded. That will need the obvious edit.

i.e. change

TARGET=prereq-0.8

to

TARGET=prereq-0.9

The script opens a tar file - if you look down lower you can see the line:

tar mxvf "../base/$TARGET.tar"

So when you change the TARGET, the script will try to open a tar with a different name.

So basically

$ tar xf prereq-0.8.tar
$ mv prereq-0.8 prereq-0.9
$ tar cf prereq-0.9.tar prereq-0.9
$ rm prereq-0.8.tar

Then make your changes to the script prereq-0.8-install, rename it to prereq-0.9-install, then use Mercurial to rename the prereq-0.8-install script. I don't know how to do that, though I suspect it is something like

$ hg rename prereq-0.8-install prereq-0.9-install

but you will need to check that. You don't need to rename the tar file in Mercurial as that's listed in .hgignore.

So basically you need to ensure that

  • The script has its version incremented - 0.9 is fine by me.
  • The TARGET at the top of the script needs to have the version changed too.
  • A tar file needs to be created which also has 0.9 in the name.

BTW, if you want to close another bug (#8566) you can delete the character "m" from the line

tar mxvf "../base/$TARGET.tar"

as that has caused portability issues for a minimal Linux system (slitaz linux), and serves no useful purpose in Sage.

It's an unusual process this script. I did not design it, and I don't like it. (Personally I would have used autoconf at the top level to create a "configure" script, which itself creates "Makefile". Then we could work like 50% of the open-source UNIX programs around which all use autoconf/automake, rather than be in the other 50% which each have their own unique ways.

Dave

comment:15 in reply to: ↑ 4 Changed 9 years ago by kcrisman

  • Status changed from needs_info to needs_review

Replying to logix:

Replying to dimpase:

One can, I suppose, just do

if [ $XCODE_VERS_MAJOR = "" ]; then
   XCODE_VERS_MAJOR="2"
fi

Well, technically in this case we might even be seeing XCode 1, but I suppose that that check will do in practice - at least if your check works with even the oldest XCode 3.x versions.

OK, you can't build Sage with XCode 2, anyway, right? So this also should be checked and the installation should exit, isn't it?

The last time I tried, it worked, but that was almost a year ago (Sage 4.4.3). I haven't tried since then, but I'll see if I manage to do so within the next couple of days.

XCode 2.4.1 worked just fine up through 4.7.alpha5 (and probably the problems I'm having with rc1 are unrelated to XCode/gcc), and 2.5 is the last one available for OS X 10.4. I think that this needs to be changed to indicate that.

comment:16 Changed 9 years ago by kcrisman

  • Status changed from needs_review to needs_work

comment:17 Changed 9 years ago by dimpase

  • Description modified (diff)

comment:18 in reply to: ↑ 14 ; follow-ups: Changed 9 years ago by dimpase

  • Status changed from needs_work to needs_info

Replying to drkirkby:

Dave,

I followed your explanations and created a patch that replaces the current prereq-0.8-install with the new prereq-0.9-install. I however did not understand whether I am also supposed to post the updated tar file.

I also cannot figure out how to make the patch respect executable permissions of prereq-0.9-install.

Changed 9 years ago by dimpase

export with --git to record file permissions

comment:19 in reply to: ↑ 18 Changed 9 years ago by dimpase

Replying to dimpase:

I also cannot figure out how to make the patch respect executable permissions of prereq-0.9-install.

sorted out this (needed to do hg export --git ...) The updated patch should respect this.

comment:20 Changed 9 years ago by kcrisman

Wow that was a lot more than I was expecting - nice.

Question:

if [ $XCODE_VERS_MAJOR -gt 2 ]; then 
        echo "You are using XCode version " $XCODE_VERS 
        echo "WARNING: You are strongly advised to install Apple's latest XCode 3," 
        echo "unless you already have it. You can download this from " 
        echo "http://developer.apple.com/xcode/" 
        echo "Sage will NOT work with XCode 4!" 

Are you trying to trip this warning for !XCode 3 as well, just as a warning to anyone who is potentially interested in upgrading, or to someone who doesn't have the latest 3.x? I assume this is the case, just checking.

comment:21 in reply to: ↑ 18 Changed 9 years ago by drkirkby

  • Reviewers set to David Kirkby

Replying to dimpase:

Replying to drkirkby:

Dave,

I followed your explanations and created a patch that replaces the current prereq-0.8-install with the new prereq-0.9-install. I however did not understand whether I am also supposed to post the updated tar file.

Yes, you do. Since it will be quite large, its probably best if you just provide a link to it.

Then a reviewer should be able to drop the new tar file in place, delete the old tar file and apply the patch.

I also cannot figure out how to make the patch respect executable permissions of prereq-0.9-install.

From what I later read, you have sorted that out.

I suggest you provide a link to the tar file and then mark this for review. I don't have OS X myself, but I can look through the changes.

Dave

comment:22 Changed 9 years ago by dimpase

  • Description modified (diff)
  • Status changed from needs_info to needs_review

OK, here comes the updated thing, ready to be tested.

comment:23 Changed 9 years ago by drkirkby

  • Status changed from needs_review to positive_review

This looks good to me. I can't test it on an OS X system with the different Xcode versions, so I'm relying on the assumption that the method for determinding the version is OK on Os X. But the script has a new version number, has the right permissions and extracts the right tar file.

Dave

comment:24 Changed 9 years ago by jdemeyer

  • Merged in set to sage-4.7.rc2
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:25 Changed 9 years ago by drkirkby

As a result of this closure, #8566 can be marked as closed and fixed.

Dave

Note: See TracTickets for help on using tickets.