#11622: Add some targets to the top-level Makefile (and other make-related
issues)
---------------------------+------------------------------------------------
Reporter: leif | Owner: leif
Type: enhancement | Status: new
Priority: major | Milestone: sage-4.7.2
Component: build | Keywords: make upgrade documentation
rebuild parallel sequential SAGE_CHECK SAGE_PARALLEL_SPKG_BUILD
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies:
---------------------------+------------------------------------------------
This perhaps just gets a meta-ticket to collect various additions (or
changes), to be discussed and implemented on their own tickets.
There are a few things I would like to have a `make` target for, partially
just for convenience (at the moment random choice / incomplete, random
order):
* `rebuild` as a short-cut (or, more precisely, the user interface) to
the currently (intentionally) undocumented
{{{
#!sh
env SAGE_UPGRADING=yes make build
}}}
which builds new / updated spkgs copied to `spkg/standard/` and also
forces the rebuild of all dependent packages.
* `build-check`, perhaps also `all-check`, as an "alias" for
{{{
#!sh
env SAGE_CHECK=yes make build
}}}
* `build-check-ignore` once we support `SAGE_CHECK=ignore` to (build and)
run all test suites without treating failed tests as fatal errors (since
e.g. the Python test suite fails on many systems)
* `build-parallel` or something like that to build Sage in parallel with
a default number of jobs (preferably the number of cores or hardware
threads), or at least (currently just) setting
`SAGE_PARALLEL_SPKG_BUILD=yes` and doing the usual thing
* `build-sequential` in case we one day default to a parallel build
* similar things for `doc` (see below) and `all`
* perhaps `library` as an alias for `./sage -b`
* ...
I could imagine to also have
* different targets to build the documentation sequentially or in
parallel (cf. #6495),
* ...
'''Please add further suggestions (and the tickets implementing them).'''
----
Related:
* As of Sage 4.7.1.rc0, running `./sage -b` before running tests is
currently not performed consistently. It's perhaps discussable whether we
should do that in ''all'' test receipts or none of them, or provide
''separate'' targets which do that (which is a trivial task except for the
choice of names).
* The current behaviour of `devel/sage/setup.py` w.r.t. to parallel
building is IMHO undesirable or sub-optimal:
* It uses the number of hardware threads even if `MAKE` isn't set (''of
course^TM^'' regardless of the system load). (If `MAKE` is set to e.g.
`make -j`, which means an "unlimited" number of jobs, it uses twice the
number of hardware threads.) [[BR]]
One can of course circumvent that by setting `MAKE` to `make -j1`,
but that's IMHO kind of odd.
* It complains about an ''"impossibly large number of threads"'' if the
number of jobs (`-j...`) found in `$MAKE` exceeds twice the number of
hardware threads, where the number of hardware threads is equal to the
number of cores on processors without what Intel calls Hyper-Threading
(HT), then falling back to (at most) the number of hardware threads.
* We should stop unsetting `MAKEFLAGS` and setting `MAKE` to `make`
whenever `SAGE_PARALLEL_SPKG_BUILD!=yes` in `spkg/install`, which is
simply wrong for a couple of reasons:
* It invalidates e.g. `MAKE=gmake`.
* It clears all flags passed to `make` on the command line as well as
those eventually added in `MAKE` (or to `MAKEFLAGS`), e.g. `-d`, `-k`
(`--keep-going`), and even `-n` (`--dry-run`) and `-q`. [[BR]]
It should instead (if at all) just add `-j1` to `MAKE` if
`SAGE_PARALLEL_SPKG_BUILD!=yes`. [[BR]]
Oh, just noticed this has meanwhile slightly changed (but don't want to
rewrite all the above):
{{{
#!sh
if [ "$SAGE_PARALLEL_SPKG_BUILD" = "yes" ] && [ -n "$MAKE" ]; then
time $MAKE -f standard/deps $1
else
time make -f standard/deps $1
fi
}}}
So we do no longer clear `MAKEFLAGS`, but not using `$MAKE` there
remains. (And this won't prevent a parallel build invoked through `-j`
without a number of jobs.) Note that `MAKE` will always be set at that
point, unless some user tries to call `spkg/install` directly (or doesn't
use GNU `make`), which is an error condition by itself, to be catched
separately.
* The sequence top-level Makefile (`make`) -> `spkg/install` (shell
script) -> `spkg/standard/deps`, another Makefile run by a ''different''
`make` instance is IMHO bad and not necessary anyway, since it is possible
to set all environment (or `make`) variables in `spkg/standard/deps` (ill
name for a Makefile that isn't included by another one) itself. [[BR]]
Changing this is of course a bigger task. (We have to keep the two-
stage make procedure, i.e. two separate Makefiles, to support upgrading at
least, which I think isn't bad since it is more modular.)
----
In case we disagree or have contrary opinions on / suggestions for some
changes or in design, we can move the discussion of ''individual aspects''
to `sage-devel` (or `sage-release` :-) ) threads, but we IMHO shouldn't
move the ''whole'' discussion there. There'll certainly be follow-up or
"real" (non-meta) tickets anyway, so it should be possible to not mix up
different aspects in a single thread.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11622>
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.
