On Fri, Jan 27, 2012 at 00:51, Georg S. Weber <georgswe...@googlemail.com> wrote: > Hi, > > so far, three distinct topics evolved in this thread: > > 1. > Make Sage not needing a C compiler, when one changed only .py files > and then types "sage -b". That's the topic of trac #12365 (see the > original post), and up to now, I read only supportive comments (to > which I say +1 also). +1 from me as well > > 2. > Discussion of using the "LLVM-backend gcc" (or even the Clang compiler > itself, which amounts to almost to the same) versus using the "FSF- > backend gcc" for Sage, at least on OS X. > > > 3. > Make Sage on OS X independent of having XCode installed. > > > > I'll concentrate on this second and third points. > FWIW, on my OS X 10.7.2 partition I was able to build Sage-4.8 using > the "FSF-backend" gcc (using the R project's gcc42 package alluded to > above), and a ptestlong run only showed doctest failures in three > files (for which I failed to make up trac tickets up to now). William > had reported these failures (all seem to be numerical noise) elsewhere > in another thread for some "LLVM-backend gcc" OS X 10.7 test build of > his. But there he reported also failures in "interrupt.pyx", which I > didn't see with the "FSF-backend gcc" build of mine. IMHO, Sage should > be able to rely on either GCC (FSF-flavour) or else Clang --- we > really shouldn't target the "LLVM-flavour gcc", since support of this > might go away soon. The LLVM project says e.g. that as of their > current 3.0 release, "llvm-gcc is no longer supported" (see > http://llvm.org/releases/3.0/docs/ReleaseNotes.html), and Apple also > seems determined to replace it with Clang as soon as possible. This > leaves three alternatives: > > a) > Stay with the old "FSF-flavor" Apple version of gcc v4.2.1 "build > 5666.3", as has been included in XCode 3.2.6, 4.0. and 4.1 (but no > longer from 4.2 onwards), and that gcc42 package. > > b) > Use newer FSF gcc's on OS X, e.g. gcc-4.4 (with the benefit of the > possibility to use an up-to-date gfortran also). +1 However, if we do release a binary based upon this, it would need to have a simple tool to switch toolchains, for developers who need to use XCode for other projects (such as iPhone apps) -- I personally am a fan of gentoo (prefix), which has the convenient gcc-config tool that makes this super simple (although, it may have to be modified to work with XCode).
> c) > Support building Sage with Clang (BTW, that's a general theme, which > is not restricted to OS X at all!) --- but both gfortran and g95 seem > to rely on the FSF gcc backends. Does any one know the status of > building some fortran compiler with/relying on nothing but Clang > (should be possible, since usually Fortran code is translated to C > code first, and only then compiled)? +1 if feasible However, according to Wikipedia (which is know to be always correct :p) "For other languages, including Java, Fortran, and Ada, LLVM remains dependent on GCC." [1] > > > Note that this still says next to nothing about point 3) above > (getting independent of XCode). If one wants to build Sage from source > on OS X, one needs not only "make" and such (which a vanilla OS X 10.7 > install does not provide), but also certain library headers (which > e.g. on Debian would be in those "dev"-packages), and the like. I'm > not sure whether there is any solution for that available yet. (Both > MacPorts and Gentoo Prefix seem to require XCode at least for > bootstrapping themselves.) However, we would only distribute a binary (most likely based upon MacPorts or Gentoo Prefix) installer, so the bootstrapping process should not be required from a users perspective (the only thing that I'm not so sure about is libc). > Especially when interfacing with Cocoa/graphics is concerned (Python > itself does this, matplotlib, R, i.e. several non-trivial components > of Sage), the respective headers are needed, and it may very well be > that only XCode provides these in a "neatly downloadable" way (those > "SDKs"). > One could patch all these parts out of Sage (they are "OS X only" > parts, after all, so Sage runs certainly without). I did that once to > get Sage building in 64bit on OS X 10.4 (for which those Cocoa parts > are supported only in 32bit), so it is definitely possible --- but > it's not some "minor" effort to get this ready for "prime-time" > mainline Sage releases, as you certainy want "plot" to show something > (maybe we would need Qt, or another alternative to Cocoa/Aqua > graphics)! > > I'd modestly suggest staying with the requirement of XCode for > building Sage from source on OS X (merely using Sage, and doing Sage > library development, is something different, though). -1 if feasible Building sage from source is part of sage development, adding XCode as a requirement will add a cost barrier (although minimal) to sage development on OSX. > > > Cheers, > Georg > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org IMO I think that we should try to make Sage compatible with clang if possible (including XCode's version), but I don't think that we should make XCode a requirement (again if possible) for OSX. Ideally, I would like to distribute (separately from sage) compatible toolchains on systems where it is difficult for a user to install one freely (i.e. OSX and Solaris). [1] http://en.wikipedia.org/wiki/Clang -- Andrew -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
