Install all dependencies with APT, reduce verbosity in Makefile build

[hattne]

Runs the CMake build with nproc CPUs everywhere; this may not work for the Makefile build, on account of recursive invocations of make. Also, using --parallel with cmake in MSYS2 sinks the ship!

[hattne]

This will run the Docker CMake build with nproc CPUs, which has previously been observed to excessively excercise the fans and slow down the build. Will throttling the Docker build by e.g. constraining the container to the first four CPUs (--cpuset-cpus=0-3) or only allowing it to consume half of the CPU capacity (--cpu-quota=50000) resolve this (see Resource constraints)?

If so, we could add something to that effect to .dev/docker/README.md; otherwise d97c2cb may have to be reverted.

@dwpaley Opinions?

[dwpaley]

Without objection here on the --parallel argument. On this branch, my laptop builds the cmake Dockerfile in a total of ~4 minutes: 1 for dependencies, 2 for the build, <1 to test.

It's funny that --parallel `nproc` works when simply --parallel doesn't, because how else is cmake deciding how many jobs to create? But it's not important.

About the source of the Python dependencies--I worry a bit because when installing thru APT we have less flexibility to choose versions. Currently APT on ubuntu 24:04 gives python 3.12.3 and Numpy 1.26.4; conda create -n test numpy gives python 3.13.5 and numpy 2.3.1. Of course the real answer would be to add explicit control of versions if we really care about it. In that event we might have to switch back to Conda, but this way is fine for now.

[dwpaley]

thank you, maybe my shift key is defective

[hattne]

About the source of the Python dependencies--I worry a bit because when installing thru APT we have less flexibility to choose versions. Currently APT on ubuntu 24:04 gives python 3.12.3 and Numpy 1.26.4; conda create -n test numpy gives python 3.13.5 and numpy 2.3.1. Of course the real answer would be to add explicit control of versions if we really care about it. In that event we might have to switch back to Conda, but this way is fine for now.

Thanks, Dan! I'm not overly concerned about the different Python versions. The SWIG step, which I suppose is what the tests are supposed to exercise, doesn't really depend on Python. But the module that a Python interpreter builds from the SWIG output is specific to the version of the interpreter.

I think I see your point, though: if the SWIG input has bunch of version-conditionals there could be trouble! Nevertheless, given your approval, I'll merge this unless there are any objections within the next day or so.

[dwpaley]

Definitely fine to merge. I was thinking of the version of numpy that the tests run on. The tests contain some lines like: d = numpy.frombuffer(s,numpy.uint32) which admittedly looks safe wrt numpy1/numpy2 issues. Confirming this in CI through a version matrix could be a future project.