If threading is added, I think we need something like this in CMake:

option(SIMDUTF_ENABLE_THREADS "thread support" ON)
if(SIMDUTF_ENABLE_THREADS)
  find_package(Threads REQUIRED)
  target_add_library(something_that_requires_threads PRIVATE Threads::Threads)
  target_compile_definitions(something_that_requires_threads PRIVATE SIMDUTF_THREADS_ENABLED=1)
endif()

Right?

If we now require multithreading support for building simdutf, this requires changes to...

https://github.com/simdutf/simdutf/blob/master/cmake/simdutf-config.cmake.in

E.g., we should add...

include(CMakeFindDependencyMacro)
if("@ SIMDUTF_ENABLE_THREADS@")
  find_dependency(Threads)
endif()

Otherwise, this will break some builds.

I guess it's quite promising, especially for our CI, which runs multitude of tests on so many platforms and compilers.

We can parallelize the builds with an additional flag... cmake --build build ▶️ cmake --build build -j (we could do even more so by configuring with Ninja).

Alternatively, we may think about running single test from executable, similarly to https://cmake.org/cmake/help/git-master/module/GoogleTest.html#command:gtest_discover_tests.

I tested this approach. We provide the same set of command line arguments as GTest and can use gtest_discover_tests. I think it's way better solution, as we can freely use all ctest facilities and do not clutter our code with threads and related stuff.