• AutoToolsSEP

SEP: Using AutoTools as Build system for Sage

This SEP proposes to switch the Sage build system to the standard autotools (automake, autoconf, etc.).

Requirements

The top level build process needs to

• Verify the needed prerequisites are present
• Setup the build environment
• Unpack and build each spkg (in order) each of which has its own (upstream-dictated) build framework

Proposal

In keeping with Sage's philosophy of not reinventing the wheel, Sage should use a well established build system. Sage should follow the standard procedure of

./configure && make && sudo make install

in order to install itself system wide and

./configure --prefix=$HOME/sage && make && make install

to install into directory sage.

Advantages

• Automake generates a number of standard targets that need not be hand-code. (What ones?)
• Makes the Sage build machinery more portable.
  • Can this be made more specific? What in particular is currently not portable?

• Hardcode SAGE_ROOT into the sage and sage-* scripts at configure time. (Would this impact relocating sage?)

  • This would break relocation which Sage has been able to do for quite awhile. If we did this, then users who installed binaries in non-standard places would have to set environment variables (like Axiom and FriCAS). It would also be more cumbersome / error-prone when you're trying to work with multiple binary installations of Sage.
• Options to configure would be passed to sub-packages (like, for example, Singular)
• Clear distinction of Sage core (i.e. the bolts) and its third-party parts (NTL, GAP, Pari, Singular, MPFR, Maxima, etc.)
• Checking system features is done at configure time and thus can abort early if something is missing.
  • This is the purpose of the prereq spkg. It basically runs a configure script to make sure that everything needed is installed.

Disadvantages

• Changing a .py file must be followed by "make install" in order to be visible in an installed Sage session.
• Probably different development workflow for new Sage code.

• SPackages must be downloaded before configure is run. make should never have a need to access the Internet.

  • (spkgs should be installed by a debian like package system, not make.)

  • What portable package systems are there?
• Automake would add another level of complexity to the build process, in particular one which is not understood by many in the community.