Fix parallel quick tests

[drwells]

In-progress fix for #6589.

There are two separate issues here: I have fixed just one so far.

1. CMake essentially generates the rule

test:
    ctest quick_tests

so the number of processes we start make (or ninja) with is irrelevant: there is no way AFAICT to pass along the number of available jobs to ctest. The first commit just uses the number of CPUs, which is nearly always what we want (we could divide this by 2 if we wanted to be more conservative).

2. For reasons I do not fully understand, we cannot do make -j2 test when we link the example programs against deal_II.g (deal_II doesn't work either). Linking against other libraries seems fine. Its irrelevant whether or not we need the libraries; just adding deal_II.g to the link line makes cmake misbehave.

[drwells]

Interestingly, make -j2 test works when compiling just base, but fails the moment we add another sublibrary (lac).

[drwells]

I managed to make a much simpler MWE: https://github.com/drwells/cmake-bug-check. This is probably a bug in CMake since the generated makefiles are not quite right.

[drwells]

I recommend that we go ahead with the current version of this PR that parallelizes the number of tests run at once. I do not like hardcoding the parallelization scheme but I don't see any other way to get this, and it is almost always what we want to do anyway.

[tjhei]

I don't quite understand, we have a simple rule that the Makefile target test will run ctest quick_tests. Why does it matter if you run the make command with -j?

Is make somehow passing the -j flag down so that make that is run from inside ctest gets them too?

Is this problem related to the fact that we are overwriting the "test" target, which is discouraged in cmake?

[tjhei]

and it is almost always what we want to do anyway.

Except when we run out of memory this way. I don't mind too much that make test is slow, to be honest.

[drwells]

Why does it matter if you run the make command with -j?

I don't know: I am pretty sure that this is a bug in CMake.

Renaming the target to check doesn't seem to help (nor does renaming it to foobar), so I don't think it is related (though naming it test is bad for other reasons).

I do not believe that flag is propagated in any way to ctest.

Except when we run out of memory this way. I don't mind too much that make test is slow, to be honest.

Perhaps we could have two such targets, and one runs in parallel? I have only ever wanted to run it in parallel, personally.

[tjhei]

Perhaps we could have two such targets, and one runs in parallel? I have only ever wanted to run it in parallel, personally.

I don't care too much about it, I just thought I would point out that waiting a few more minutes vs OOM might be better for an inexperienced user.

[drwells]

I went ahead and checked the memory usage and I think its okay. Its difficult to profile these things, but if I compile and run every test at once on my machine (after clearing all OS caches) then I use about 5 GB of RAM: I think any machine with at least 22 virtual cores has that much memory available. If we wanted to be conservative we could divide the number of jobs in 2, but I don't think its necessary.