./configure --prefix=SAGE_LOCAL

Question

./configure --prefix=SAGE_LOCAL

Closed this issue 9 years ago · 157 comments

I propose to support choosing a location for the SAGE_LOCAL tree, using

./configure --prefix=SAGE_LOCAL

(the default would be, as before, the local subdirectory of SAGE_ROOT - see patch on the ticket).

I am fully aware that Sage's build system does not have a separation between 'make' and 'make install'; see #21495 for that.

Nevertheless, SAGE_LOCAL should be considered the same as the prefix in the sense of the autotools.

This ticket is a step towards #21566.

Release manager configure tarball: http://sage.ugent.be/www/jdemeyer/sage/configure-214.tar.gz

CC: @jdemeyer @embray @kiwifb @nexttime @dimpase

Component: build

Author: Matthias Koeppe, Jeroen Demeyer

Branch: e5926b1

Reviewer: Jeroen Demeyer, Erik Bray, Matthias Koeppe

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

Answer 1 · 2016-09-12T18:16:32.000Z

Branch: u/mkoeppe/__configure___prefix_sage_local

Answer 2 · 2016-09-12T18:17:21.000Z

Description changed:

--- 
+++ 
@@ -3,7 +3,7 @@
 ```
 ./configure --prefix=SAGE_LOCAL
 ```
-(the default would be, as before, the `local` subdirectory of SAGE_ROOT).
+(the default would be, as before, the `local` subdirectory of SAGE_ROOT - see patch on the ticket).
 
 I am fully aware that Sage's build system does not have a separation between 'make' and 'make install' (this would require all packages to support a two-stage install (DESTDIR).) Nevertheless, SAGE_LOCAL should be considered the same as the `prefix` in the sense of the autotools.

Answer 3 · 2016-09-12T18:17:21.000Z

New commits:

`fa16fae`	`Use AC_PREFIX_DEFAULT to default prefix to SAGE_ROOT/local`

Answer 4 · 2016-09-12T18:17:21.000Z

Commit: fa16fae

Answer 5 · 2016-09-12T18:17:37.000Z

Author: Matthias Koeppe

Answer 6 · 2016-09-15T00:50:57.000Z

Description changed:

--- 
+++ 
@@ -5,6 +5,8 @@
 ```
 (the default would be, as before, the `local` subdirectory of SAGE_ROOT - see patch on the ticket).
 
-I am fully aware that Sage's build system does not have a separation between 'make' and 'make install' (this would require all packages to support a two-stage install (DESTDIR).) Nevertheless, SAGE_LOCAL should be considered the same as the `prefix` in the sense of the autotools.
+I am fully aware that Sage's build system does not have a separation between 'make' and 'make install'; see #21480 for that. 
+
+Nevertheless, SAGE_LOCAL should be considered the same as the `prefix` in the sense of the autotools.

Answer 7 · 2016-09-15T00:51:23.000Z

Description changed:

--- 
+++ 
@@ -5,7 +5,7 @@
 ```
 (the default would be, as before, the `local` subdirectory of SAGE_ROOT - see patch on the ticket).
 
-I am fully aware that Sage's build system does not have a separation between 'make' and 'make install'; see #21480 for that. 
+I am fully aware that Sage's build system does not have a separation between 'make' and 'make install'; see #21495 for that. 
 
 Nevertheless, SAGE_LOCAL should be considered the same as the `prefix` in the sense of the autotools.

Answer 8 · 2016-09-15T07:21:02.000Z

comment:6

(i completely agree with this)

a main obstacle is: the build system writes to $prefix during the build...

i suggest to do the transition one-package-at-a-time, and after --disable-$package is in place.

with --disable-all, it will be easiest to avoid writing to $prefix.

Answer 9 · 2016-09-15T07:26:41.000Z

comment:7

On this short term ticket, we do allow "make" to write into $prefix; and "make install" will be a no-op.

More ambitious plans are to be discussed on the long term ticket #21495, not on this ticket. Thanks.

Answer 10 · 2016-09-15T09:49:47.000Z

comment:8

i agree that there are intermediate steps to take. but i don't yet fully understand this approach.

i think the behaviour of just "make" should not change, regardless of --prefix. it works perfectly well and as intended right now. clearly it should do something different under the hood, but that's not on this ticket.

we do allow "make" to write into $prefix

why would you need/want that? can you please give an example?

my feeling is, that entangling prefix and SAGE_LOCAL further complicates the transition considerably. there will be no way to tell whether "this part still uses SAGE_LOCAL" vs. "this has already been cleaned". newcomers tend to grep a variable from the code, see how it is used and use it the same way. for a looong time to come.

Answer 11 · 2016-09-15T10:55:24.000Z

Changed author from Matthias Koeppe to Matthias Koeppe, Jeroen Demeyer

Answer 12 · 2016-09-15T11:08:17.000Z

Description changed:

--- 
+++ 
@@ -8,5 +8,3 @@
 I am fully aware that Sage's build system does not have a separation between 'make' and 'make install'; see #21495 for that. 
 
 Nevertheless, SAGE_LOCAL should be considered the same as the `prefix` in the sense of the autotools.
-
-

Answer 13 · 2016-09-15T11:08:17.000Z

Changed author from Matthias Koeppe, Jeroen Demeyer to Matthias Koeppe

Answer 14 · 2016-09-15T11:08:17.000Z

comment:10

I made a new ticket (#21501) to allow $SAGE_LOCAL to be changed.

Answer 15 · 2016-09-15T11:08:17.000Z

Dependencies: #21501

Answer 16 · 2016-09-15T13:49:54.000Z

comment:11

i wrote

entangling prefix and SAGE_LOCAL further complicates the transition considerably.

@mkoeppe i've thought about it. it seems, the alternatives are much worse (#21501) or much more ambitious.

please go ahead with prefix==SAGE_LOCAL.

please consider to add a remark in some documentation (better place: configure --help?) on this temporary sort of prefix, such as

"currently, make install is a no-op, that will change (hopefully). you should not expect a fully functional installation in $prefix before make install has finished."

Answer 17 · 2016-09-15T16:51:31.000Z

comment:12

Thanks Felix for the discussion.

If you want to help, could you work on rebasing #15105.

Answer 18 · 2016-09-18T05:17:41.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`64e697d`	`Allow a custom $SAGE_LOCAL directory`
`dc81cf6`	`Merge remote-tracking branch 'trac/u/jdemeyer/ticket/21501' into t/21479/__configure___prefix_sage_local`
`ac12edc`	`Merge tag '7.4.beta5' into t/21479/__configure___prefix_sage_local`
`924b30b`	`Handle --prefix`

Answer 19 · 2016-09-18T05:17:41.000Z

Changed commit from fa16fae to 924b30b

Answer 20 · 2016-09-18T05:19:36.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`6f8eaac`	`Fixup`

Answer 21 · 2016-09-18T05:19:36.000Z

Changed commit from 924b30b to 6f8eaac

Answer 22 · 2016-09-18T05:22:58.000Z

comment:15

Here's a first version of what I have in mind.

Some concerns:

bootstrap. It's somewhat unclear what to do here. By the way, is it supposed to use the distribution's Python or ours?
sage-location.

Answer 23 · 2016-09-18T11:09:50.000Z

comment:16

I don't like the duplication in build/make/install and src/bin/sage-env.

Here is a suggestion: add a new file, say src/bin/sage-config (or whatever you want to call it) to deal with configurable things like SAGE_LOCAL. You can also define the other SAGE_* directories (except SAGE_ROOT) there.

Then you can source this file in both src/bin/sage-env and build/make/install, which can then be independent of configure.

And I don't see the point of changing $SAGE_ROOT/sage because that is additional duplication.

Answer 24 · 2016-09-18T13:13:06.000Z

comment:17

Replying to @mkoeppe:

Some concerns:

bootstrap. It's somewhat unclear what to do here. By the way, is it supposed to use the distribution's Python or ours?

sage-location.

In both cases, I don't get what the problem is.

Answer 25 · 2016-09-18T19:29:41.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`c9091f5`	`Have sage-env, sage, install read in generated file sage-env-config`
`66fc193`	`Fix for locating sage-env-config from sage-env`

Answer 26 · 2016-09-18T19:29:41.000Z

Changed commit from 6f8eaac to 66fc193

Answer 27 · 2016-09-18T19:31:18.000Z

comment:19

Replying to @jdemeyer:

Here is a suggestion: add a new file, say src/bin/sage-config (or whatever you want to call it) to deal with configurable things like SAGE_LOCAL. You can also define the other SAGE_* directories (except SAGE_ROOT) there.

Thanks for the suggestion.
The ticket is indeed simpler that way.
Please take a look.

Answer 28 · 2016-09-18T19:56:26.000Z

comment:20

For easier testing, I plan to review this after #21501 and #21480 are in a beta release. You can remind me when that happens.

Answer 29 · 2016-09-24T17:47:42.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`e0dc9a3`	`Merge tag '7.4.beta6' into t/21479/__configure___prefix_sage_local`

Answer 30 · 2016-09-24T17:47:42.000Z

Changed commit from 66fc193 to e0dc9a3

Answer 31 · 2016-09-25T02:07:39.000Z

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

`751bd0f`	`Reword TODO item`
`3a8cc0e`	`Fix typo in comment`
`0dd9c50`	`Respect environment variable MAKE`
`17f90d8`	`beautification`
`e5f9065`	`More comments`
`7791cd9`	`Remove --buildbase code`
`74169e7`	`Pass SAGE_SRC to generate_py_source.mk`
`0394333`	`Add new file to MANIFEST.in`
`fdedb02`	`Install SAGE_LOCAL/bin/sage instead of SAGE_ROOT/sage as Jupyter kernel`
`8215254`	`Merge branch 't/21480/keep_src__clean_by_using___build_base_when_building_sagelib' into t/21479/__configure___prefix_sage_local`

Answer 32 · 2016-09-25T02:07:39.000Z

Changed commit from e0dc9a3 to 8215254

Answer 33 · 2016-09-25T02:08:21.000Z

comment:23

Branch is now on top of 7.4.beta6 (which has #21501) + #21480.

Answer 34 · 2016-09-25T02:10:01.000Z

Description changed:

--- 
+++ 
@@ -8,3 +8,5 @@
 I am fully aware that Sage's build system does not have a separation between 'make' and 'make install'; see #21495 for that. 
 
 Nevertheless, SAGE_LOCAL should be considered the same as the `prefix` in the sense of the autotools.
+
+This ticket is a step towards #21566.

Answer 35 · 2016-09-26T12:10:53.000Z

comment:25

Replying to @mkoeppe:

Here's a first version of what I have in mind.

Some concerns:

bootstrap. It's somewhat unclear what to do here. By the way, is it supposed to use the distribution's Python or ours?

Just to answer this question: the bootstrap package is intended to use the system Python (after all, it's needed well before Sage's Python is ever built).

Answer 36 · 2016-10-13T05:27:48.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`06fe631`	`Merge tag '7.4.rc1' into t/21479/__configure___prefix_sage_local`

Answer 37 · 2016-10-13T05:27:48.000Z

Changed commit from 8215254 to 06fe631

Answer 38 · 2016-10-13T05:29:31.000Z

comment:27

Branch is now on top of 7.4.rc1.

Jeroen - ready for review.

Answer 39 · 2016-10-19T00:43:07.000Z

Changed commit from 06fe631 to 1adc18c

Answer 40 · 2016-10-19T00:43:07.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`1adc18c`	`Merge tag '7.4' into t/21479/__configure___prefix_sage_local`

Answer 41 · 2016-10-19T00:43:22.000Z

comment:29

Now on top of 7.4.

Answer 42 · 2016-10-25T19:01:01.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`d82cfbc`	`Merge tag '7.5.beta0' into t/21479/__configure___prefix_sage_local`

Answer 43 · 2016-10-25T19:01:01.000Z

Changed commit from 1adc18c to d82cfbc

Answer 44 · 2016-10-26T21:58:41.000Z

comment:32

What does this comment mean:

## The first test does not actually work (see above).

("see above" can be really confusing because you don't know where to look.

Comments like these don't belong in the sources but in a Trac ticket:

	# TODO: Making directories in $prefix
	# should be done by 'make', not configure.

# TODO: Should the install hierarchy (local) really be deleted by make distclean?

#SAGE_ENV_DIR=`dirname $0`    ### Does not work. $0 is /bin/bash

## Note this is a bashism, not sure if this is allowed in this file.

Answer 45 · 2016-10-26T22:05:38.000Z

comment:33

Then a more serious remark: I doubt that you are using BASH_SOURCE correctly. From the bash man page:

       BASH_SOURCE
              An array variable whose members are the source filenames where the corresponding shell function names in the FUNCNAME array variable  are
              defined.  The shell function ${FUNCNAME[$i]} is defined in the file ${BASH_SOURCE[$i]} and called from ${BASH_SOURCE[$i+1]}.

At the very least, I need more explanation of why your code does the right thing.

Answer 46 · 2016-10-27T00:18:59.000Z

comment:35

Replying to @jdemeyer:

What does this comment mean:
## The first test does not actually work (see above).
("see above" can be really confusing because you don't know where to look.

It's referring to dirname $0 -- which does not give the location of sage-env but rather /bin/bash. This is because sage-env is sourced (.) rather than executed.

Note this is existing code in sage-env which simply never worked.

Comments like these don't belong in the sources but in a Trac ticket:

I know, these comments are for the reviewer. I'll be happy remove them after we had a discussion about them... So do you have a comment on these?

	# TODO: Making directories in $prefix
	# should be done by 'make', not configure.

# TODO: Should the install hierarchy (local) really be deleted by make distclean?

#SAGE_ENV_DIR=`dirname $0`    ### Does not work. $0 is /bin/bash

## Note this is a bashism, not sure if this is allowed in this file.

Answer 47 · 2016-10-27T00:25:37.000Z

comment:36

Replying to @jdemeyer:

Then a more serious remark: I doubt that you are using BASH_SOURCE correctly. From the bash man page:
       BASH_SOURCE
              An array variable whose members are the source filenames where the corresponding shell function names in the FUNCNAME array variable  are
              defined.  The shell function ${FUNCNAME[$i]} is defined in the file ${BASH_SOURCE[$i]} and called from ${BASH_SOURCE[$i+1]}.
At the very least, I need more explanation of why your code does the right thing.

BASH_SOURCE[0] gives the source of the "currently running function". See https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html (you need to read the entries for FUNCNAME and BASH_SOURCE).

Answer 48 · 2016-10-27T06:09:27.000Z

comment:37

Replying to @mkoeppe:

Replying to @jdemeyer:
What does this comment mean:
## The first test does not actually work (see above).
("see above" can be really confusing because you don't know where to look.
It's referring to dirname $0 -- which does not give the location of sage-env but rather /bin/bash. This is because sage-env is sourced (.) rather than executed.

Don't tell me but tell the person reading sage-env (i.e. clarify the comment in the file).

I know, these comments are for the reviewer. I'll be happy remove them after we had a discussion about them... So do you have a comment on these?

Comments for the reviewer can go on Trac.

Answer 49 · 2016-10-27T15:58:54.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`c5998ea`	`Remove TODO comment; reflected in #21775`
`bd8d2c7`	`Remove TODO comment; reflected in #21524`
`ce48cf8`	`src/bin/sage-env: Improve comments`
`c347768`	`src/bin/sage-env: Remove broken "dirname $0" code`

Answer 50 · 2016-10-27T15:58:54.000Z

Changed commit from d82cfbc to c347768

Answer 51 · 2016-10-27T16:00:12.000Z

comment:39

OK, done; please take a look

Answer 52 · 2016-10-30T06:16:32.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`4275121`	`Installation manual: Document configure --prefix`

Answer 53 · 2016-10-30T06:16:32.000Z

Changed commit from c347768 to 4275121

Answer 54 · 2016-11-01T21:21:01.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`ea994cc`	`Merge tag '7.5.beta1' into t/21479/__configure___prefix_sage_local`

Answer 55 · 2016-11-01T21:21:01.000Z

Changed commit from 4275121 to ea994cc

Answer 56 · 2016-11-03T03:47:47.000Z

comment:42

ping?

Answer 57 · 2016-11-04T13:28:25.000Z

comment:43

Running ./configure without arguments:

[...]
config.status: creating build/make/Makefile-auto
config.status: creating src/Makefile
config.status: creating src/bin/sage-env-config
config.status: executing depfiles commands
config.status: executing mkdirs commands
config.status: creating directory /usr/local/src/sage-config/logs/pkgs
config.status: creating directory NONE
config.status: creating directory NONE/bin
config.status: creating directory NONE/etc
config.status: creating directory NONE/include
config.status: creating directory NONE/lib
config.status: creating directory NONE/share
config.status: creating directory NONE/var/lib/sage/installed
config.status: creating symbolic link lib64 -> lib

Answer 58 · 2016-11-04T13:28:25.000Z

Changed dependencies from #21501 to none

Answer 59 · 2016-11-04T13:28:25.000Z

Reviewer: Jeroen Demeyer

Answer 60 · 2016-11-04T13:36:04.000Z

comment:44

This is just because you write SAGE_LOCAL instead of "$SAGE_LOCAL".

When you fix this, I suggest to squash the commits to one commit and rebase to 7.5.beta1.

Answer 61 · 2016-11-04T13:37:49.000Z

comment:45

The file sage-env-config needs to be ignored by .gitignore and deleted when running make distclean.

Answer 62 · 2016-11-04T13:54:03.000Z

comment:46

This line in sage needs quoting:

. $SAGE_ROOT/src/bin/sage-env-config

And since you're running bash anyway, you might as well use source instead of . which is more visible.

Answer 63 · 2016-11-04T13:54:55.000Z

comment:47

And do you really need this:

if [ $? -ne 0 ]; then
    echo >&2 "Error: $SAGE_ROOT/src/bin/sage-env-config could not be read"
fi

The shell will already write an error message, no need for an additional message.

Answer 64 · 2016-11-04T13:55:44.000Z

comment:48

I also think that determining $SAGE_LOCAL should be done after

# If this is a freshly-unpacked binary tarball then run the installer
# Note: relocate-once.py deletes itself upon successful completion
if [ -x "$SAGE_ROOT/relocate-once.py" ]; then
    "$SAGE_ROOT/relocate-once.py"
fi

Answer 65 · 2016-11-04T13:59:16.000Z

comment:49

Can you explain under which circumstances it is needed to read sage-env-config from sage-env? It seems to me that sage-env-config would already be read, either by the top-level sage script or by build/make/install.

Answer 66 · 2016-11-04T14:00:25.000Z

comment:50

It is good style to start all error messages with Error: and write them to stderr. build/make/install doesn't do that.

Answer 67 · 2016-11-06T22:21:58.000Z

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

`4f832c2`	`Add configure option --prefix=SAGE_LOCAL`

Answer 68 · 2016-11-06T22:21:58.000Z

Changed commit from ea994cc to 4f832c2

Answer 69 · 2016-11-06T22:22:28.000Z

comment:52

Squashed and rebased on 7.5.beta1

Answer 70 · 2016-11-06T22:42:08.000Z

Changed commit from 4f832c2 to 5fcda83

Answer 71 · 2016-11-06T22:42:08.000Z

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

`6308c3b`	`Add configure option --prefix=SAGE_LOCAL`
`ff48d5a`	`Fixup configure without --prefix`
`67baa7a`	`Source sage-env-config after calling relocate-once.py`
`5fcda83`	`top-level sage script: Remove redundant sage-env-config error message`

Answer 72 · 2016-11-06T22:51:00.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`1d0aa34`	`src/bin/sage-env-config: Prefix error message with 'Error:'`
`a0f90af`	`make misc-clenan: Delete src/bin/sage-env-config`
`e525547`	`Add sage-env-config to .gitignore`

Answer 73 · 2016-11-06T22:51:00.000Z

Changed commit from 5fcda83 to e525547

Answer 74 · 2016-11-06T22:52:09.000Z

Branch pushed to git repo; I updated commit sha1. New commits:

`600639a`	`sage-env: Quoting fix`

Answer 75 · 2016-11-06T22:52:09.000Z

Changed commit from e525547 to 600639a

Answer 76 · 2016-11-06T23:00:33.000Z

comment:56

Replying to @jdemeyer:

Can you explain under which circumstances it is needed to read sage-env-config from sage-env? It seems to me that sage-env-config would already be read, either by the top-level sage script or by build/make/install.

$SAGE_LOCAL/bin/sage becomes directly executable; one does not have to go through that top-level script.

Answer 77 · 2016-11-06T23:01:53.000Z

comment:57

Replying to @jdemeyer:

since you're running bash anyway, you might as well use source instead of . which is more visible.

I'm not sure, I like . more than source.

Answer 78 · 2016-11-07T11:15:08.000Z

comment:59

Replying to @mkoeppe:

$SAGE_LOCAL/bin/sage becomes directly executable; one does not have to go through that top-level script.

Then let me turn the question around: why do you need to change $SAGE_ROOT/sage?

Answer 79 · 2016-11-07T11:20:09.000Z

comment:60

I'm still not entirely convinced that BASH_SOURCE[0] really does what we want. Why not use $SAGE_ROOT/src/bin/sage-env-config?

Or maybe we should just source both sage-env-config and sage-env from src/bin/sage?

Answer 80 · 2016-11-08T12:47:28.000Z

comment:62

Replying to @jdemeyer:

Why not use $SAGE_ROOT/src/bin/sage-env-config?

Things installed in SAGE_LOCAL definitely should not depend on the source directory.

Or maybe we should just source both sage-env-config and sage-env from src/bin/sage?

That would be possible. There might be a few more places though that need to source the extra file.

Answer 81 · 2016-11-08T12:53:16.000Z

comment:63

Replying to @jdemeyer:

Replying to @mkoeppe:

$SAGE_LOCAL/bin/sage becomes directly executable; one does not have to go through that top-level script.

Then let me turn the question around: why do you need to change $SAGE_ROOT/sage?

$SAGE_ROOT/sage sources $SAGE_ROOT/src/bin/sage-env-config so that it works when nothing has been installed so far.

Answer 82 · 2016-11-08T13:10:19.000Z

comment:64

Replying to @mkoeppe:

$SAGE_ROOT/sage sources $SAGE_ROOT/src/bin/sage-env-config so that it works when nothing has been installed so far.

Sorry, I don't follow. What is the "it" in the sentence above? In other words, what would not work?

Answer 83 · 2016-11-20T03:17:32.000Z

Changed commit from 600639a to a3467bf

Answer 84 · 2016-11-20T03:17:32.000Z

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

`f6c4513`	`Add configure option --prefix=SAGE_LOCAL`
`7d44f0b`	`Fixup configure without --prefix`
`387ab94`	`Source sage-env-config after calling relocate-once.py`
`fc66139`	`top-level sage script: Remove redundant sage-env-config error message`
`fe19d3f`	`src/bin/sage-env-config: Prefix error message with 'Error:'`
`269ad80`	`make misc-clean: Delete src/bin/sage-env-config`
`727123a`	`Add sage-env-config to .gitignore`
`be4c390`	`sage-env: Quoting fix`
`a3467bf`	`top-level sage script: No need to source sage-env-config`

Answer 85 · 2016-11-20T08:32:08.000Z

comment:66

Replying to @jdemeyer:

Replying to @mkoeppe:

$SAGE_ROOT/sage sources $SAGE_ROOT/src/bin/sage-env-config so that it works when nothing has been installed so far.

Sorry, I don't follow. What is the "it" in the sentence above? In other words, what would not work?

I retract my comment.

I have removed this code from $SAGE_ROOT/sage.
(Also rebased on latest beta.)

Answer 86 · 2016-11-23T07:58:01.000Z

comment:67

Replying to @mkoeppe:

Or maybe we should just source both sage-env-config and sage-env from src/bin/sage?

That would be possible. There might be a few more places though that need to source the extra file.

I think I wouldn't like to change this on this ticket. There are indeed a few places that source sage-env: build/bin/sage-spkg, build/make/deps, src/bin/sage-update-src. Probably not so nice if we have to change all of them.

Answer 87 · 2016-11-23T08:01:37.000Z

comment:68

Replying to @mkoeppe:

$SAGE_LOCAL/bin/sage becomes directly executable; one does not have to go through that top-level script.

I realized that this is not entirely true. sage-env contains some code for discovering SAGE_ROOT when it is not set, but that code fails if $SAGE_LOCAL is not a direct subdirectory of $SAGE_ROOT.
I suppose I could add the definition of SAGE_ROOT to sage-env-config.
But that could go on a follow-up ticket as well.

Answer 88 · 2016-12-29T17:30:27.000Z

comment:70

ping

Answer 89 · 2016-12-29T20:39:49.000Z

Changed reviewer from Jeroen Demeyer to Jeroen Demeyer, Erik Bray

Answer 90 · 2016-12-29T20:39:49.000Z

comment:71

Looks good to me at least, but I don't have a complete view of the implications. I also still think #21495 has merit, but that shouldn't hold this up, as it's a step in the right direction I think regardless of what anyone thinks about #21495 or if anything is done about it.

Answer 91 · 2017-01-13T07:55:30.000Z

comment:73

Doesn't work if you dont have autotools

19make -j2 build/make/Makefile
20make[1]: Entering directory `/home/buildbot/slave/sage_git/build'
21make[1]: warning: -jN forced in submake: disabling jobserver mode.
22./bootstrap -d
23make[2]: Entering directory `/home/buildbot/slave/sage_git/build'
24rm -rf config configure build/make/Makefile-auto.in
25make[2]: Leaving directory `/home/buildbot/slave/sage_git/build'
26src/bin/sage-env: line 206: /home/buildbot/slave/sage_git/build/src/bin/sage-env-config: No such file or directory
27sage-env: Error: /home/buildbot/slave/sage_git/build/src/bin/sage-env-config could not be read.
28./bootstrap: line 31: aclocal: command not found
29Bootstrap failed, downloading required files instead.
30./bootstrap: line 61: sage-download-file: command not found
31Error: downloading configure-200.tar.gz failed
32make[1]: *** [configure] Error 1
33make[1]: Target `build/make/Makefile' not remade because of errors.
34make[1]: Leaving directory `/home/buildbot/slave/sage_git/build'
35make: *** [start] Error 2
36program finished with exit code 2

Answer 92 · 2017-01-21T23:04:56.000Z

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

`928f67d`	`Add configure option --prefix=SAGE_LOCAL`
`66a8066`	`Fixup configure without --prefix`
`b5ecc81`	`Source sage-env-config after calling relocate-once.py`
`c1c36ff`	`top-level sage script: Remove redundant sage-env-config error message`
`ae6263b`	`src/bin/sage-env-config: Prefix error message with 'Error:'`
`27189be`	`make misc-clean: Delete src/bin/sage-env-config`
`eb922b8`	`Add sage-env-config to .gitignore`
`4cdaa43`	`sage-env: Quoting fix`
`71f88cc`	`top-level sage script: No need to source sage-env-config`
`52826b1`	`bootstrap: Don't use sage-env, set PATH directly`

Answer 93 · 2017-01-21T23:04:56.000Z

Changed commit from a3467bf to 52826b1

Answer 94 · 2017-01-21T23:07:13.000Z

comment:76

Replying to @vbraun:

Doesn't work if you dont have autotools

Thanks for catching this.
Fixed. Needs review.

Answer 95 · 2017-01-27T02:34:52.000Z

comment:77

Erik, if you could take another look...

Answer 96 · 2017-01-27T14:34:32.000Z

comment:78

I'm not really clear about what changed. I don't understand what the issue with autotools was or how this was fixed. I see that you did do something to address that but I don't understand the original issue in the first place--would be better if Volker commented since he pointed it out.

Answer 97 · 2017-02-04T16:21:48.000Z

comment:79

Jeroen, could you take another look?

Answer 98 · 2017-03-01T11:44:30.000Z

comment:80

This ticket needs review.

Answer 99 · 2017-03-09T08:42:15.000Z

comment:81

pong

Answer 100 · 2017-03-09T14:33:02.000Z

comment:82

Why does this require changes to bootstrap anyway?