On 14 Dez., 16:36, Dima Pasechnik <dimp...@gmail.com> wrote: > actually, this idea won't fly on OSX, IMHO. > Using a non-Xcode compiler on OSX looks next to impossible. >
On OS X, the approach to "include our own GCC 4.5.1" is doomed to fail. We could ship our own gcc-apple 4.2.1 for all supported Mac platforms (10.4 Tiger, 10.5 Leopard, 10.6 Snow Leopard; Intel as well as PowerPC), even including the corresponding gcc fortran parts --- I'm playing around with Gentoo Prefix, which is capable of doing that --- but that would mean that for OS X, we would need to ship an extra (Apple version of) GCC (in both the binary as well as source distribution case). But even on Linux, there is far more than meets the eye. Just some of the potential show-stoppers: - the C library/runtime of the underlying system - the C++ library/runtime (a very different beast from the above) of the underlying system - the binutils (assembler and such) of the underlying system (e.g. on Mac, these are special) - the kernel headers of the underlying system - the loader/linker to be used for the "Sage distribution" (the "system" one, or also some "battery" included?) and last but not least, as a first step, you always will have to build the "Sage" gcc first if you use a Sage source distribution. And gcc has as dependencies e.g. the gmp, mpfr, and mpc libraries (I think gettext also), so in addition to e.g. mpir, we always would need to distribute these, too. And make sure that they build with the "system" complier, since the "Sage" gcc is not available yet! Last, but not least: building our own gcc might be *far* more difficult on certain system settings, than building the whole current Sage distribution (without gcc) ... and the Sage project has even less competence sorting out the problems that *will* arise with compiling gcc, than for packages like mpir, or pari. Instead of increasing the number of (even now hardly maintainable) Sage spkg's, currently I favor a different approach: 1. Split up Sage into a "mathematical" core distribution, and a generic "base distribution". 2. The former might very well be a "Python package" and distributable as such. 3. The latter would contain all these libpng, tachyon, patch, diffutils (not yet in Sage), and whatnot parts, that are better maintained outside the Sage project. 4. Do still provide such a "base distribution" for some time to come, but make sure it can be easily and readily replaced by, say, an on-top- of-your-system Gentoo Prefix, or directly by the underlying system used, i.e. Debian/Ubuntu/your favourite Linux distribution/Cygwin/... The latter would mean e.g. in the case of Debian, that there is a Debian "Sage package", which tells its dependencies the Debian package management (apt/dpkg), so that the necessary "base distribution" parts get automatically installed as dependencies. Likewise for RPM-based distributions, or Cygwin --- all the mechanisms are already there. Very finegranular, so we can say that Sage x.y.z needs tachyon version u.v.w, neither an older nor a newer version ... In short: Instead of including only the gcc, do provide some complete "hosted distribution" (like Gentoo Prefix is, or UWIN, or NixPkg, or NetBSD may be used for; or on Mac OS X: Fink, Macports; or on Windows: Cygwin, MSys/MingW) environment for Sage --- but don't you reinvent the wheel, rather re-use something that exists. And is well-maintained without the need of much time from Sage project developers. 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
