Revision history [back]

Since you are compiling Sage on a powerful virtual machine, i would advise not touching the build system, just not to lose your time. If you absoluely want to do that, you can disable the compilation of some standard packages by declaring them optional (for this, you will have to edit the fiie SAGE_ROOT/build/pkgs/<package>/type for each <package>, and run ./configure again), but you will experience a lot of issues (unsatisfied dependencies).

Now, if you speak about runtime, you can remove some automatic imports at startup. The Sage modules are imported in SAGE_ROOT/src/sage/all.py, and it recursively calls the contents of SAGE_ROOT/src/sage/<module>/all.py for each <module>.

By the way, i would be interested to see how you deploy your build infrastructure (i personaly have some hand-made build system that is used to build some specific patchbots, Sage Dabian Live (and a bunch of Sage binaries a few years ago), and i was thinking whether it is worth cleaning them and why not extend them to build such weird images, hence i would be glad to see your approach).

Since you are compiling Sage on a powerful virtual machine, i would advise not touching the build system, just not to lose your time. If you absoluely want to do that, you can disable the compilation of some standard packages by declaring them optional (for this, you will have to edit the fiie SAGE_ROOT/build/pkgs/<package>/type for each <package>, and run ./configure again), but you will experience a lot of issues (unsatisfied dependencies).

Now, if you speak about runtime, you can remove some automatic imports at startup. The Sage modules are imported in SAGE_ROOT/src/sage/all.py, and it recursively calls the contents of SAGE_ROOT/src/sage/<module>/all.py for each <module>.

By the way, i would be interested to see how you deploy your build infrastructure (i personaly have some hand-made build system that is used to build some specific 32bit patchbots, Sage Dabian Live (and a bunch of Sage binaries a few years ago), and i was thinking whether it is worth cleaning them and why not extend them to build such weird images, hence i would be glad to see your approach).

Since you are compiling Sage on a powerful virtual machine, i would advise not touching the build system, just not to lose your time. If you absoluely want to do that, you can disable the compilation of some standard packages by declaring them optional (for this, you will have to edit the fiie SAGE_ROOT/build/pkgs/<package>/type for each <package>, and run ./configure again), but you will experience a lot of issues (unsatisfied dependencies).dependencies). Some simple removals are doable (e.g. removing both r and ryp2).

Now, if you speak about runtime, you can remove some automatic imports at startup. The Sage modules are imported in SAGE_ROOT/src/sage/all.py, and it recursively calls the contents of SAGE_ROOT/src/sage/<module>/all.py for each <module>.

By the way, i would be interested to see how you deploy your build infrastructure (i personaly have some hand-made build system that is used to build some specific 32bit patchbots, Sage Dabian Live (and a bunch of Sage binaries a few years ago), and i was thinking whether it is worth cleaning them and why not extend them to build such weird images, hence i would be glad to see your approach).