Re: Test parallelism with CMake

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Freitag, den 22.10.2021, 09:10 -0400 schrieb Greg Hogan:
> The cmake-build-system does defer to gnu-build-system, which calls
> `make test -jN`; however, CMake generated Makefile specifies 'test'
> as a single target (the Ninja generator suffers from the same issue)
> so `ctest` is run without parallelism.
That does sound like a CMake bug.  Has no one on their end addressed
that like since the inception of CMake?

> To run CMake tests with parallelism the cmake-build-system should
> directly call `ctest` with the configured parallelism (same '-jN'
> argument). The cmake-build-system's check method is essentially
> untouched from March, 2013 (commit c6bded8a) so this issue has
> existed from the beginning.
> 
> I made an inelegant patch to my local guix repo, essentially
> replacing cmake-build-system:check with a copy of gnu-build-
> system:check and changing 'apply invoke "make" test-target' to 'apply
> invoke "ctest"'. This works, although the package I was working on
> requires parallel tests to be disabled. Once the expectation is set
> that code will be run serially it is difficult to change the default
> to parallel execution.
> 
> It seems that we should at a minimum document the issue in cmake-
> build-system:check. We could patch cmake-build-system to enable test
> parallelism and explicitly disable that setting for packages which
> succeed before but fail after making the change. What do you think?
I'm not too sure on any of this.  For one, we'd have to survey whether
really all CMake-based packages use ctest to build and not any other
tool of their choosing.  Next, we'd have to adjust the calling
conventions to add support for ctest command syntax, given that it is
indeed another tool with probably conventions from make itself. 
Finally, messing with cmake-build-system would most likely result in a
world rebuild, so we can realistically do this on core-updates.

Regards,
Liliana