Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta-ticket: Make sage (the distribution) behave like a standard autotools package, to the extent possible #21566

Open
mkoeppe opened this issue Sep 22, 2016 · 25 comments

Comments

@mkoeppe
Copy link
Contributor

mkoeppe commented Sep 22, 2016

The goal of this ticket is to be able to explain to experienced Unix users what sage-the-distribution is, as follows:

If you download sage-the-distribution and do

./configure --prefix=/SOMEWHERE && make 

then that's the same as doing a sequence of about 100 times:

wget SOMEPACKAGE.tar.gz && tar xf SOMEPACKAGE.tar.gz && (cd SOMEPACKAGE \
&& ./configure --prefix=/SOMEWHERE && make && make install)

(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:

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:

Included on this ticket are the following steps.

Implement standard features expected of an autotools build system.

Clean up parts of the build system to make it more standard. This is to make it straightforward for developers familiar with the autotools system to contribute to sage.

Make the separation between sage-the-distribution and sagelib (sage-the-Python-library) clearer. This will be beneficial for distributions such as Debian etc.

Following are workarounds to enable root-owned installation hierarchies (prefix).

See also:

CC: @vbraun @jdemeyer @kiwifb @embray @dimpase @williamstein @mezzarobba @tobihan @timokau @jhpalmieri @seblabbe

Component: build

Author: Matthias Koeppe

Issue created by migration from https://trac.sagemath.org/ticket/21566

@mkoeppe mkoeppe added this to the sage-7.5 milestone Sep 22, 2016
@mezzarobba
Copy link
Member

comment:3

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)?

@embray
Copy link
Contributor

embray commented Sep 23, 2016

comment:4

(Sorry, the comment that was here previously was meant to go on #21507 -- I have too many tabs open)

@mkoeppe
Copy link
Contributor Author

mkoeppe commented Sep 23, 2016

comment:5

Replying to @mezzarobba:

Do you intend ./configure to detect already installed dependencies so that make skips installing them? (Eventually? as part of this task?)

That is beyond the scope of this task ticket. But I would be interested in a follow-up ticket to this effect.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@embray
Copy link
Contributor

embray commented Oct 5, 2016

comment:9

Will this also fix how make actually runs configure for you, and that configure gets invoked even if you run make clean targets?

@mkoeppe
Copy link
Contributor Author

mkoeppe commented Oct 5, 2016

comment:10

Replying to @embray:

Will this also fix how make actually runs configure for you,

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.

@mkoeppe

This comment has been minimized.

@embray
Copy link
Contributor

embray commented Oct 6, 2016

comment:11

Replying to @mkoeppe:

Replying to @embray:

Will this also fix how make actually runs configure for you,

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.

@jdemeyer
Copy link

jdemeyer commented Oct 6, 2016

comment:12

Replying to @embray:

Will this also fix how make actually runs configure for you, and that configure gets invoked even if you run make clean targets?

In standard autotools packages, the Makefile gets created by configure, so you wouldn't be able to run make clean either without configure.

@embray
Copy link
Contributor

embray commented Oct 7, 2016

comment:13

True--in that case it should (hopefully) be a moot point. This is currently a huge annoyance for me.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@embray
Copy link
Contributor

embray commented Jan 9, 2017

comment:18

Do we have a ticket somewhere for adding more configure-time checks for system packages? If there is I can't find it.

It's a little outside the scope of this ticket but not entirely. There are quite a few system packages installed by sage that could be skipped if we added the appropriate scripts to check for them.

@jdemeyer
Copy link

jdemeyer commented Jan 9, 2017

comment:19

Replying to @embray:

Do we have a ticket somewhere for adding more configure-time checks for system packages? If there is I can't find it.

No, we don't. Feel free to open a ticket. I would prefer one ticket for every package, not a single ticket trying to do too much.

@embray
Copy link
Contributor

embray commented Jan 9, 2017

comment:20

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.

@mkoeppe

This comment has been minimized.

@mkoeppe
Copy link
Contributor Author

mkoeppe commented Jul 7, 2017

comment:22

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

@embray
Copy link
Contributor

embray commented Jul 10, 2017

comment:23

Replying to @mkoeppe:

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).

@mkoeppe mkoeppe modified the milestones: sage-7.5, sage-9.2 May 1, 2020
@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe mkoeppe changed the title Task ticket: Make sage (the distribution) behave like a standard autotools package, to the extent possible Meta-ticket: Make sage (the distribution) behave like a standard autotools package, to the extent possible May 1, 2020
@mkoeppe

This comment has been minimized.

@mkoeppe mkoeppe modified the milestones: sage-9.2, sage-9.3 Oct 24, 2020
@mkoeppe
Copy link
Contributor Author

mkoeppe commented Feb 13, 2021

comment:30

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants