#11926: "make build" should run Sage once
------------------------+---------------------------------------------------
Reporter: jdemeyer | Owner: GeorgSWeber
Type: defect | Status: needs_review
Priority: major | Milestone: sage-4.7.3
Component: build | Keywords: Makefile build
Work_issues: | Upstream: N/A
Reviewer: | Author: Jeroen Demeyer
Merged: | Dependencies:
------------------------+---------------------------------------------------
Comment(by leif):
Replying to [comment:23 jdemeyer]:
> Replying to [comment:16 leif]:
> > Still, running `sage` (especially the full bunch of shell scripts)
there is quite dangerous, as almost everything can happen.
> Whoever built Sage will have to run it sooner or later, otherwise it's
quite pointless building Sage. So the danger is there anyway.
:D I didn't know that. I only build Sage, but have never run it.
Seriously, the difference is whether a user ''intentionally'' runs `sage`
(for the first time after a build / upgrade / extraction of a binary
distribution), and ''sees'' what's happening. Your new patch omits the
redirection to `/dev/null`, but I think it would be better to log the
output to something like {{{$SAGE_ROOT/first_sage_startup-`date
+"%Y-%m-%d-%H:%M"`.log}}}, which we ''could'' delete afterwards if
apparently nothing went wrong, otherwise point the user to this file, e.g.
for bug reports (also to sage-release btw.).
We have enough "error reports" where people claim something didn't work
but couldn't provide error logs.
[[BR]]
I'd also prefer running Sage from the `Makefile`; rather than changing the
`build` target, we could modify the ''default target'' to run `sage` once
after a successful build (or after building the documentation, but that's
likely to fail in "weird" ways if `sage` itself doesn't work properly),
perhaps just if no (recent) "first run" logfile exists.
There we should IMHO separate what's currently implicitly performed by
`sage-location`, for example by adding an option to `sage-sage` for
running just that. For upgrades, running `sage-location` ''afterwards''
is not strictly necessary; although some parts should be run by `sage-
spkg` anyway, such that they also get run upon e.g. `sage -i ...`. If
`SAGE_UPGRADING=yes`, we could add a message to `spkg/install` (or `sage-
sage`, or `sage-update`) recommending to try to run `sage` ''right now''
(provided the build succeeded). `make upgrade` (and `make rebuild`) are
overdue anyway; if/when we drop the creation of `pipestatus`, we could
also change `sage-update` to just ''download'' new files and then run
`make rebuild`, i.e., make it use the top-level `Makefile` as well (which
is now under revision control and hence subject to upgrades, too).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11926#comment:26>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
