On 10/30/07, Paul Zimmermann <[EMAIL PROTECTED]> wrote:
> I wonder about the size of the SAGE installation. I just compiled sage-2.8.10
> on my computer and did:
>
> mermoz% make install DESTDIR=/local/spaces/logiciels/sage-2.8.10/p4
>
> which uses more than 1Gb of memory:
>
> mermoz% du -s /local/spaces/logiciels/sage-2.8.10/p4
> 1013988 /local/spaces/logiciels/sage-2.8.10/p4
>
> which is essentially the same memory as the build directory:
>
> mermoz% du -s .
> 1010052 .
>
> I'm not sure all the files need to be installed, in particular all the *.spkg
> files and all the *.[cho] files:
>
> mermoz% du -s /local/spaces/logiciels/sage-2.8.10/p4/sage/spkg
> 165940 /local/spaces/logiciels/sage-2.8.10/p4/sage/spkg
One can replace the spkg's by empty files with the same name.
There is an automated way to do this: If you do
sage -bdist version_number
it will create a file
SAGE_ROOT/dist/sage-version_number.tar
that is a tarball that contains a minimal sage install optimized for
redistribution. In particular all the .spkg's are empty.
The _current_ primary goal with Sage is to
"provide a truly viable alternative to Maple, Matlab, Magma,
and Mathematica... as soon as possible".
The commercial Ma* systems each have install sizes between 600MB and
3GB, so we just have to stay in that ballpark for now.
(Actually, Magma is a bit smaller than the others). That said,
we do periodically audit Sage and try to shrink things down
or remove unnecessary bloat.
Regarding general shortcomings with "make install", that make target was
written a long time ago specifically for somebody making a debian .deb
package for Sage, and I think most people using Sage don't use it, so it is
probably not nearly as good as it should be. The optimal
way to install sage is to extract the source tarball in a place like
/usr/local/sage
then build there and run it from the build location.
> 14553117 21372 -rw-r--r-- 1 zimmerma spaces 21833818 Oct 30 11:27
> /local/spaces/logiciels/sage-2.8.10/p4/sage/spkg/standard/sage-2.8.10.spkg
> 256037 6856 -rw-r--r-- 1 zimmerma spaces 7001348 Oct 30 11:23
> /local/spaces/logiciels/sage-2.8.10/p4/sage/devel/sage-main/.hg/00manifest.d
> 21510910 7688 -rw-rw-r-- 1 zimmerma spaces 7852378 Oct 30 11:24
> /local/spaces/logiciels/sage-2.8.10/p4/sage/install.log
> 27510639 1080 -rw-rw-r-- 1 zimmerma spaces 1098688 Oct 30 11:23
> /local/spaces/logiciels/sage-2.8.10/p4/sage/devel/sage-main/build/temp.linux-i686-2.5/sage/schemes/hyperelliptic_curves/frobenius_cpp.o
> 30220438 1716 -rw-rw-r-- 1 zimmerma spaces 1752092 Oct 30 11:22
> /local/spaces/logiciels/sage-2.8.10/p4/sage/devel/sage-main/sage/rings/polynomial/real_roots.c
>
Regarding files like above, it is good to have those around if you are doing
any development on the Sage library, since otherwise you'll have to wait
for them to be auto-regenerated whenever you build your changes (by typing
"sage -br"). Every single Sage install (even from a binary
distribution) is setup
with a distributed revision control system, etc., so that the user can
immediately
start doing development work on Sage and easily give back their improvements.
This has been a critical design decision in growing the Sage developer base from
1 person to over 100.
-- William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
