LAGraph: looking for GraphBLAS; CHOLMOD: merge cuda, vertcat/horzcat; ParU: enable_cuda; GraphBLAS testing

[DrTimothyAldenDavis]

CHOLMOD: merge cholmod_cuda library into main cholmod library. Fix A and B dtype checks in horzcat and vertcat.

ParU: enable_cuda (to match KLU, UMFPACK)

LAGraph: look for GraphBLAS in build tree first, so we don't get an old SuiteSparse GraphBLAS in /usr/local/include.

GraphBLAS: testing

[mmuetzel]

There seem to be two issues in CI. Both are related to how LAGraph imports GraphBLAS and its version number:

• find_package ( GraphBLAS 7.1.0 MODULE REQUIRED ) doesn't find GraphBLAS 8.3.0.
• LAGraph saves in its config file the version number of the GraphBLAS version it was built with (to avoid API issues). However, it looks like the names that we use in GraphBLAS itself for the version numbers (GRAPHBLAS_VERSION_MAJOR, GRAPHBLAS_VERSION_MINOR) differ from the ones that are created by FindGraphBLAS in LAGraph (GRAPHBLAS_MAJOR, GRAPHBLAS_MINOR).
  The variables that are used to create the LAGraphConfig.cmake file are the ones from SuiteSparse GraphBLAS. They are empty in this case. So, trying to import the LAGraph targets fails.

For the first issue, we could change that line to find_package ( GraphBLAS 7.1.0...8.3.0 MODULE REQUIRED ) (or a larger range).

For the second issue, we could either change the variable names in GraphBLASConfig.cmake or in FindGraphBLAS.cmake so that they match (and use them when creating LAGraphConfig.cmake).
Or we could add logic to "translate" from one set of variables to the other in FindGraphBLAS.cmake.

What would you prefer?

[DrTimothyAldenDavis]

I would rather change the variable names. Keep the ones I use in GraphBLAS, with GRAPHBLAS_VERSION_MAJOR etc.

For find_package: yes, the range is fine. In fact, 7.1.0...9.0.1 should work too. I have a draft of 9.0.0 and 9.0.1 that can't be released yet but it would be useful to be able to use it with LAGraph as-is.

[DrTimothyAldenDavis]

I changed the find_package from 7.1.0 to 7.1.0...9.0.1.

I also changed the name of the LAGraph project from lagraph to LAGraph. This seems to be required when running test_coverage, which is not done in SuiteSparse but it is done in the build.yaml in the LAGraph repo. This line:

SuiteSparse/LAGraph/CMakeLists.txt

Line 107 in d189df3

DEPENDENCIES ${PROJECT_NAME}

fails on Linux, it seems, because the target "lagraph" (lower case) isn't found. It worked before but not now. Lower case works on the mac (which is case insensitive for file names). If I change the project name to LAGraph (upper case):

SuiteSparse/LAGraph/CMakeLists.txt

Line 55 in d189df3

project ( LAGraph

from its original "lagraph" then the test_coverage works. This doesn't affect SuiteSparse since we don't run the test_coverage there. It does affect the LAGraph test coverge in the LAGraph repo.

I'm not sure where the name change of GRAPHBLAS_VERSION_MAJOR etc would be fixed so I haven't done that yet.

[DrTimothyAldenDavis]

Hmm, cmake doesn't like the find_package ( GRAPHBLAS 7.1.0...9.0.1 MODULE REQUIRED )

I get this error in the CI, and on my local machine when building LAGraph:

  CMake Warning at cmake_modules/FindGraphBLAS.cmake:67 (find_package):
    Could not find a configuration file for package "GraphBLAS" that is
    compatible with requested version "7.1.0".
  
    The following configuration files were considered but not accepted:
  
      /home/runner/work/SuiteSparse/SuiteSparse/GraphBLAS/build/GraphBLASConfig.cmake, version: 8.3.0
  
  Call Stack (most recent call first):
    CMakeLists.txt:149 (find_package)
  
  
  -- Could NOT find GraphBLAS (missing: GraphBLAS_DIR)
  CMake Warning (dev) at /usr/local/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:447 (message):
    `find_package()` specify a version range but the module GraphBLAS does not
    support this capability.  Only the lower endpoint of the range will be
    used.
  Call Stack (most recent call first):
    cmake_modules/FindGraphBLAS.cmake:175 (find_package_handle_standard_args)
    CMakeLists.txt:149 (find_package)
  This warning is for project developers.  Use -Wno-dev to suppress it.
  
  -- Found GraphBLAS: /home/runner/work/SuiteSparse/SuiteSparse/GraphBLAS/build/libgraphblas.so.8.3.0 (found suitable version "8.3.0", minimum required is "7.1.0") 
  -- GraphBLAS version: 8.3.0
  -- GraphBLAS include: /home/runner/work/SuiteSparse/SuiteSparse/GraphBLAS/Include
  -- GraphBLAS library: /home/runner/work/SuiteSparse/SuiteSparse/GraphBLAS/build/libgraphblas.so.8.3.0
  -- GraphBLAS static:  /home/runner/work/SuiteSparse/SuiteSparse/GraphBLAS/build/libgraphblas.so
...

I don't know how to fix that.

[DrTimothyAldenDavis]

Actually, there is a much better option:

(1) the version range can be enabled by adding HANLDLE_VERSION_RANGE, but it's limited. It can only do things like 3.4.0...3.4.9. The major and minor numbers must match. That's useless for LAGraph + GraphBLAS, which needs 7.10...9.0.1, for example

(2) LAGraph can rely on any GraphBLAS library and the version number of that library would be arbitrary.

(3) If using SuiteSparse::GrapBLAS, the best solution is for LAGraph.h to detect if SuiteSparse is in use, and if so, the header file LAGraph.h can raise an #error if the version number is not OK.

This makes the version checking in FindGraphBLAS.cmake irrelevant, so LAGraph can just do:

find_package ( GraphBLAS MODULE REQUIRED )

[mmuetzel]

That sounds reasonable. We probably don't even need that guard on the header. It might be nice to be able to build the LAGraph in SuiteSparse with a different GraphBLAS, too.

We would probably still need to have the (correct) version number of GraphBLAS that was used to build it in LAGraphConfig.cmake. Currently it checks for matching major and minor version for ABI/API compatibility. Is that correct?