Add option for building without GraphBLAS and Mongoose

[jtojnar]

Is your feature request related to a problem? Please describe. Seeing that GraphBLAS and Mongoose have their own repositories and can be built independently of SuiteSparse, it is more convenient for us as Linux distro packagers to do that. Unfortunately, the makefile does not allow us to do that easily.

Describe the solution you'd like Add an option like IGNORE_STANDALONE_TOOLS that would prevent GraphBLAS and Mongoose from building and installing like MY_METIS_LIB does for metis.

Describe alternatives you've considered Alternately, distros could:

1. Build individual libraries explicitly (basically reproducing the commands run by make in their own scripts and deleting the unwanted lines). — This might be something we want to do in the future but at the moment the libraries are too interlinked.
2. Edit the Makefile to remove unwanted lines. — This is what we are doing now.

[DrTimothyAldenDavis]

GraphBLAS is something you'll want to include soon, in all Linux distros, since it's a widely anticipated package supported by Intel, NVIDA, IBM, and Redis (used in RedisGraph). GraphBLAS already appears as a Google-supported package in the Google Cloud, as used by Redis, for example. So I don't think a feature to disable GraphBLAS will be useful ... you'll soon need to include GraphBLAS, anyway, in all distros, and likely Mongoose too.

[DrTimothyAldenDavis]

In addition, I plan on using GraphBLAS throughout SuiteSparse, so decoupling them would be difficult.

[jtojnar]

We do include GraphBLAS, just in a separate package. Disabling it here would allow us not to build it twice. Also the build seems to be much slower compared to the rest of SuiteSparse so having it in a separate package is more convenient since it allows us to build it much faster.

Would it be possible to support using GraphBLAS from the system like we can do with metis?

[DrTimothyAldenDavis]

Oh I see. I misunderstood what you were asking. Yes, that’s a reasonable idea. I’ll reopen this issue.

[tornaria]

Note that a side effect of 9e65b8bc1427fc99d4bd6f229b60a615eccc7d7e is that running make install from the top directory will run make without target for GraphBLAS and Mongoose.

In particular this will try to run demo for Mongoose, which breaks cross compilation (see https://github.com/void-linux/void-packages/pull/36423#issuecomment-1083306444).

In our void linux template we use:

• make library for build step
• make go for check step
• make install for install step The check step is skipped on cross builds, but build+install should not run compiled binaries if this is to cross build (since void linux builders are all x86 hardware, no cross builds mean no support for other architectures like aarch64).

Here's the patch I'm using on top of 5.12.0 to fix the issue:

--- a/Makefile
+++ b/Makefile
@@ -294,7 +294,7 @@ endif
 # just compile GraphBLAS
 gb:
 	echo $(CMAKE_OPTIONS)
-	( cd GraphBLAS && $(MAKE) JOBS=$(JOBS) CMAKE_OPTIONS='$(CMAKE_OPTIONS)' )
+	( cd GraphBLAS && $(MAKE) JOBS=$(JOBS) CMAKE_OPTIONS='$(CMAKE_OPTIONS)' library )
 
 # compile and install GraphBLAS libgraphblas_renamed, for MATLAB
 gbrenamed:
@@ -309,7 +309,7 @@ gbrenamed:
 
 # just compile Mongoose
 mon:
-	( cd Mongoose && $(MAKE) CMAKE_OPTIONS='$(CMAKE_OPTIONS)' )
+	( cd Mongoose && $(MAKE) CMAKE_OPTIONS='$(CMAKE_OPTIONS)' library )
 
 # compile and install Mongoose
 moninstall: mon

I'd appreciate if you could ensure, when implementing the current issue, that make library and make install don't run compiled binaries (feel free to take the patch above if it suites you).

[StefanBruens]

In addition, I plan on using GraphBLAS throughout SuiteSparse, so decoupling them would be difficult.

Have the plans evolved furhter on this?

As building GraphBLAS is much more time consuming (especially on architectures where very fast CPUs are more seldom), we would like to split of the building of GraphBLAS from the remainder of Suitesparse. This allows to commence with building other packages directly or indirectly depending on Suitesparse (e.g. via eigen3), and only block packages actually depending on GB.

Changing this would be moot when significant parts of Suitesparse would depend on GB.

[DrTimothyAldenDavis]

Julia, RedisGraph, and a Python interface to GraphBLAS written by Anaconda ( to br used by NetworkX) all use GraphBLAS.

For now, no other packages inside SuiteSparse rely on GraphBLAS. That will change soon though, when I add LAGraph to SuiteSparse.

[StefanBruens]

These are all leaf packages, so build time is of a lesser concern. Eigen3 is used throughout almost any package doing linear algebra, so build time is important. As long as LAGraph can be built independently from the remainder of Suitesparse, and is used only in a few places this would not change much.

[DrTimothyAldenDavis]

Right. All of the SuiteSparse packages can be compiled independently. The top-level Makefile is very simple and its use is optional. If you want to build just AMD, COLAMD, and UMFPACK, say, then just add a script:

( cd AMD && make && make install )
( cd COLAMD && make && make install )
( cd UMFPACK && make && make install )

etc. Or, a script could dive into each Package/build folder and do "cmake .. ; make ; make install".

I don't have a single script (cmake or Makefile) that can build just selected packages (I suppose you could comment-out the packages you don't want).

In the most distant future, the GraphBLAS build time will drop drastically, when I add a JIT. Then I can compile the kernels at run time, from source, as I need them.

[davidak]

The SuiteSparse repo contains a fork of Mongoose with some changes to the build system, but also

integers: int (32-bit) and SuiteSparse_long (nominally 64-bit) replaced with int32_t and int64_t.

https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/dev/Mongoose/Doc/ChangeLog

If that is needed for later versions of SuiteSparse to work properly, it is not possible to use Mongoose provided by the system.

To keep software maintainable, it would be good to try to upstream the changes, but Mongoose seem to be abandoned (last release 2019). If you have the resources, you could take over the project or maintain a proper fork in it's own repo.

Otherwise this issue can not be solved, at least for Mongoose (haven't looked into GraphBLAS).

[DrTimothyAldenDavis]

The version of Mongoose inside the SuiteSparse repo is the primary version now. I've already taken over its maintenance.

[mmuetzel]

A root CMakeLists.txt file was recently added to the dev2 branch of SuiteSparse. Using it with the appropriate flags will allow to select which libraries should be be built. https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/25ef28cd0c0ad3fbe944ef9e217672b9b31e7a6e/README.md?plain=1#L653-L660

That would probably help with this use case once it made it into a release.

[DrTimothyAldenDavis]

Thanks for the suggestion, @jtojnar, and thanks for the update, @mmuetzel. This is now updated in SuiteSparse 7.4.0, in the default dev branch of the SuiteSparse repo. I'll release a 7.4.0.beta1 soon.