Closed 8f46c63a-2596-4880-ba93-a09d8ba6c056 closed 10 years ago
In Sage right now, you can set the variable SAGE_KEEP_BUILD_SPKGS
to not delete the temporary build directories. For an individual spkg installation, you can also do sage -i -s blah.spkg
: the -s
flag says to save (keep) the build directory. Note that keeping all of the build directories can take up a lot of disk space, so it is not a good idea to turn it on by default.
(This also doesn't quite do what you want: if you install an spkg once and then again, it will start over from scratch. You can manually change to the build directory, though, and do whatever recompilation or reinstallation you need.)
These features are documented in the installation guide.
Replying to @jhpalmieri:
Note that keeping all of the build directories can take up a lot of disk space, so it is not a good idea to turn it on by default.
I see your point about space consumption. Maybe it should be switched on with some sort of developer mode
, or just if .git is present.
(This also doesn't quite do what you want: if you install an spkg once and then again, it will start over from scratch. You can manually change to the build directory, though, and do whatever recompilation or reinstallation you need.)
Exactly, that's why i have created the ticket. Rebuilding, installing or exporting packages should not require manual intervention (nor recompilation).
Replying to @jhpalmieri:
In Sage right now, you can set the variable
SAGE_KEEP_BUILD_SPKGS
to not delete the temporary build directories.
SAGE_KEEP_BUILT_SPKGS that is...
Another odd thing is that you can't just test an spkg (after it's been built / installed) even if you kept its build directory [other than by starting a Sage subshell, changing to the directory and running ./spkg-check
].
And rerunning (parts of) spkg-install
is usually also an adventure.
Replying to @nexttime:
Another odd thing is that you can't just test an spkg (after it's been built / installed) even if you kept its build directory [other than by starting a Sage subshell, changing to the directory and running
./spkg-check
].
Package operations must be controlled from toplevel. The packages don't know their dependencies (currently), and spkg-install files are not in a shape to do anything else. Running checks can be done with make <packagename>-check
(in my implementation).
And rerunning (parts of)
spkg-install
is usually also an adventure.
The spkg-install programs must be idempotent (of course). Just like make install
is for all sane packages. (It's not hard to fix this!).
I think I should add something like AC_ARG_ENABLE([keepbuilt]...)
. I don't see a reason why it should be disabled in case .git
is present. How are rebuilds caused by branch change implemented/handled currently?
Given that this is already an option (either using the environment variable or using the -s
option), can this be closed as "wontfix"?
Replying to @jdemeyer:
Given that this is already an option (either using the environment variable or using the
-s
option), can this be closed as "wontfix"?
it will not solve the problem. before you notice, the source has gone.
go ahead and close the ticket. try to make sure that i am the only one.
Changed author from Felix Salfelder to none
Reviewer: Felix Salfelder
Replying to @sagetrac-felixs:
it will not solve the problem. before you notice, the source has gone.
go ahead and close the ticket. try to make sure that i am the only one.
You speak in mysteries to me. But I will do as you suggested and close the ticket.
The current build mechanism unconditionally deletes
build/pkgs/$packagename/src
. This should be triggered manually (or upon package update).Fixing this requires
src
tosrc-$version
(or something equivalent), to avoid confusionComponent: build
Keywords: build src clean
Reviewer: Felix Salfelder
Issue created by migration from https://trac.sagemath.org/ticket/14792