(and about a 50 times pip install SOMEPACKAGE).
sage-the-distribution has figured out the right order of installing these packages, tricky configure options so that everything works, and on top has fixes for various outdated/handwritten/missing build systems of various packages.

Thus it is beyond the scope of this ticket:

to separate make and make install. Our make install is a no-op. ANY discussion of this needs to go to ticket #21495, not here.

We will implement this goal without sacrificing any of the traditional convenience features that Sage-the-distribution has provided for the casual user (such as sage -i for installing packages; and that ./configure is an optional step of the installation process).

We have a separate task ticket for the following:

#21507: Make sagelib (sage-the-Python-library) a normal Python package, installable by setup.py, pip, etc. and eventually even via PyPI. We will NOT turn sagelib to an automake package (which was proposed in #14807).

(There will be some interaction with some of the steps of that ticket.)

Included on this ticket are the following steps.

Implement standard features expected of an autotools build system.

Choosing the installation hierarchy (configure --prefix=SAGE_LOCAL). Right now it is the subdirectory local of SAGE_ROOT.

By allowing the user to choose the installation hierarchy, there are new requirements. What is installed there should run without requiring environment variables to be set. It should not refer to the environment variables SAGE_LOCAL, or SAGE_ROOT (or SAGE_SRC_ROOT). An exception could perhaps be made for the latter for "debugging" or "source inspection" facilities:

Change History (23)

Do you intend ./configure to detect already installed dependencies so that make skips installing them? (Eventually? as part of this task?) For example, is the idea that ./configure would finish by saying something like “the following dependencies are missing: ... please install them, or type make and I'll install my own copy”? (This wouldn't be quite standard, but close enough, while staying mostly compatible with the installation procedure of sage-the-distribution.)

Or would sage-the-distribution still always have its private version of everything, so that users would have to choose between installing it and installing sagelib directly (e.g., via pip)?

No, probably not. For this ticket, I want to keep configure an optional step of the installation process. (I've updated the description.)

and that configure gets invoked even if you run make clean targets?

Not sure about this one. To keep this ticket manageable, I want to change the top-level Makefile as little as possible. But please do open a ticket that describes make clean issues that ought to be addressed.

No, probably not. For this ticket, I want to keep configure an optional step of the installation process. (I've updated the description.)

I guess it would be fine to make it an optional step. But I don't think it should be a mandatory step for all make targets, and currently it is, or at least seems to be. For example if I run make maintainer-clean twice in a row, the second time will run configure only to delete its output.

This is especially annoying on Cygwin where configure is extremely slow.

I agree--I probably won't even make a ticket for every package right away but I will make a master ticket for coordinating the task, and then open individual tickets for packages that I think are most worth tackling.

Would someone who has followed recent build system changes be interested in updating the description of this meta-ticket?

Which build system changes specifically? I have a few open tickets that are making some not insignificant changes, but they don't terribly change things for this ticket. If anything they will help make it easier to implement the goals of this ticket. There is one small conflict I can see: The work I'm doing in #22509 and in #23160 will mostly supersede the work you already did in #21537. This is because the sdh_make_install helper function I added will also handle $SAGE_SUDO.

Right now I'm working toward the goals I outlined ​here for improving support for building Sage against dependencies from the system. However, I haven't even made tickets for every aspect of that plan yet. All the work I'm currently doing is toward #22509 and #22510 which I see as necessary for saner package management in Sage (they will also be very helpful for work I need to do of making it easier to install optional packages with the Windows installer, but that's otherwise an orthogonal issue).