On 5 Nov., 21:24, "Justin C. Walker" <jus...@mac.com> wrote:
> On Nov 5, 2011, at 12:16 , Julien Puydt wrote:
>
> > Le 05/11/2011 17:42, William Stein a écrit :
> >> What do you base this "probably" on? Having started and watched Sage
> >> "evolve" of over 6 years, if anything it is not evolving in the
> >> direction you suggest.
>
> > Fair point. But that can't last.
>
> Trying to make a "self-contained" system that utilizes a wide variety of
> system-provided libraries is an exercise leading to premature grey hair and
> high blood pressure.
>
> There are so many different versions of each library and system (for Linux,
> in particular) that it's a practical impossibility to produce a package like
> Sage that will work on the systems currently supported.
Well, one could check much more in Sage's 'configure', and eventually
instruct the user to install (or update) some system packages and/or
download additional spkgs, probably specific to the system (e.g. MacOS
X, Cygwin, Solaris).
We could keep the bloated "[almost] everything included" "source"
tarball, but could also offer a stripped-down one which doesn't carry
all that unnecessary baggage (like Cephes, iconv, termcap, readline,
gfortran binaries(!), patch, Mercurial, ...).
Projects like Sage-on-Gentoo show that it's possible to use much more
system packages / libraries than we do, and shipping all *by*
*default* (without any option to omit some packages), some just doing
if [ "$UNAME" = foo ]; then
# no need to build it on 'foo'
exit 0
fi
or building vanilla upstream without any Sage-specific configuration
(except --prefix=...) is certainly suboptimal, although probably
easier to maintain (modulo issues *we* have to deal with that would
otherwise get reported upstream, either package or OS / distribution).
As discussed elsewhere, a first step would be to split off the Sage-
specific parts of spkgs from the upstream tarball / source tree. We'd
also need better dependencies, with version number matching, a
distinction between build and runtime requirements, etc. pp., i.e.
modular, formal package metadata (which could include our current
build scripts, although they'd also better be split into pieces, with
a lot factored out).
-leif
--
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
