Provide SuiteSparseConfig.cmake

[gruenich]

It would ease using SuiteSparse with CMake, if SuiteSparse would provide a SuitSparseconfig.cmake file, that CMake can use to identify the SuiteSparse installation and get all locations and parameters.

CMake offers the helper function configure_package_config_file, to get this done without too much work. If you are interested, I can provide an according merge request.

[DrTimothyAldenDavis]

It's on my TODO list. It requires some changes to the codes, however. In many of my codes, I generate multiple versions for double, complex, etc. I do that by setting some -D flags and compiling the source twice (or 4x, depending on how many variants a package has). That works fine in a Makefile, but it complicates a CMake script. I need to rework the source code so it compiles once, yet still generates the versions I need. It's not hard to do, I just need to spend the time to refactor the codes.

[sergiud]

There's native CMake support including relocatable package config in my fork.

[jdumas]

@sergiud how does your fork compares to suitesparse-metis-for-windows? I've looked at your CMake a bit and have some suggestions to facilitate :

• Prefix CMake options and target names by suitesparse to avoid conflicts
• Provide alias target names such as SuiteSparse::cholmod
• Use BLAS::BLAS and LAPACK::LAPACK target names for compatibility with CMake's official imported target names for blas/lapack.
• Check ff targets BLAS::BLAS and LAPACK::LAPACK are provided by the user, and if so, do not call find_package(BLAS) or find_package(LAPACK) (e.g. let the user provide their own target beforehand).
• Add option to force compilation of LGPL modules as SHARED libraries (even if BUILD_SHARED_LIBS is OFF)
• Right now it is not possible to disable GPL modules, as spqr target will fail to compile.

[sergiud]

Thanks for the suggestions. However, many of these seem to target add_subdirectory use which was not my primary focus. I prefer ExternalProject.

suitesparse-metis-for-windows mentions the use of Python for preprocessing source files (although less relevant for the end user). My implementation does not use any additional tools except CMake. Additional support includes:

• Intel MKL on Windows works out of the box (requires additional logic and some patching)
• Netlib LAPACK compiled using MinGW can be used to compile SuiteSparse in Visual Studio (requires patching)
• CUDA works out of the box
• Relocatable package config
• CPack for generating binary/source archives
• (CMake unrelated but implemented using CMake functionality) correct DLL export on Windows/hidden symbols (-fvisibility=hidden by default)

Some of these features might be also supported by suitesparse-metis-for-windows by now.

I should note, I offered the CMake implementation to @DrTimothyAldenDavis back in 2016. However, since this required me to give up all the rights, we could not reach an agreement which would allow to integrate the CMake support into official distributions. To my knowledge, @DrTimothyAldenDavis has been working for some time on his own CMake support implementation.

[jdumas]

Thanks. ... I hope we can get some official support for CMake at some point.

However, many of these seem to target add_subdirectory use which was not my primary focus. I prefer ExternalProject.

True, but one doesn't prevent the other ... I've integrated your CMake via add_subdirectory(), and it works fine with some workaround (e.g. I'm using MKL to replace BLAS/LAPACK). With some minor tweaks it would work great for both use cases.

[DrTimothyAldenDavis]

I now have a completely new CMake build system for SuiteSparse (v6.0.0, soon to be released as a tagged beta pre-release).

It required some substantial changes to many of the packages, since I used to compile individual source files multiple times. I no longer need to do that, so the cmake scripts are very simple.

I have a SuiteSparse_config/cmake_modules folder with cmake scripts that handle SuiteSparse policy, the BLAS, and I have "Find*.cmake" scripts now for all of my packages and for all of my package dependencies (GMP, MPFR).

The SuiteSparseBLAS.cmake is very handy, as well.

Regarding CUDA: I now detect if it's avaiable. It can also be disabled by setting ENABLE_CUDA to false.

[jdumas]

That's great to hear. I do hope that this new CMake system aims to also support subproject builds (via add_directory()). Specifically I hope that there is a way to provide existing targets for dependencies (such as BLAS::BLAS or gmp::gmp) to bypass any provided Find*.cmake script.

[DrTimothyAldenDavis]

SuiteSparse now has a completely new cmake-based build system. I'm still working on a few minor updates in a pending v6.0.2 version, but it's mostly in place now.

[DrTimothyAldenDavis]

p.s. If there are any issues with the new build system, please add them as a new issue. Thanks again for all the great feedback!