Add some targets to the top-level Makefile

[nexttime]

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

• build-check, perhaps also all-check, as an "alias" for

env SAGE_CHECK=yes make build

• 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
• similar things for doc and all

CC: @kiwifb @jdemeyer @jhpalmieri

Component: build

Keywords: make upgrade documentation rebuild parallel sequential SAGE_CHECK SAGE_PARALLEL_SPKG_BUILD

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

[jdemeyer]

comment:3

There are some changes to the top-level Makefile at #11969, needs_review.

[jdemeyer]

Replying to @nexttime:

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

We don't have SAGE_CHECK=ignore yet, so this isn't applicable.

• build-sequential in case we one day default to a parallel build

Well, we don't build in parallel by default.

• perhaps library as an alias for ./sage -b

Very bad idea. We shouldn't encourage ./sage -b, just run make or make build or make sagelib if needed.

[jdemeyer]

Replying to @nexttime:

It's perhaps discussable whether we should do that in all test receipts

It is done in all test targets.

[jdemeyer]

Replying to @nexttime:

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

    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.

Neither of this is still true.

[jdemeyer]

Replying to @nexttime:

it is possible to set all environment variables in build/make/Makefile itself.

I don't think so (or at least, I don't know how to do it). In any case, I don't see the point of repeating all environment variables in build/make/Makefile, what's wrong with keeping the use of sage-env?

[jdemeyer]

Replying to @nexttime:

• build-sequential in case we one day default to a parallel build

We still don't do that by default.

[jdemeyer]

comment:17

I propose to use pbuild and pall as target names, by analogy to ptest(long).

I don't see the need for a target pdoc (I never need to run make doc, I just run make which is mostly the same anyway).

[mkoeppe]

comment:18

Outdated, should close

[jhpalmieri]

comment:19

There might be something with some validity here, but we can always open a new ticket with a more clear focus.