Reason for not shipping the mumps sources

[eike-fokken]

Is there a reason you don't just upload all the different mumps version as a git history into this repo, so users don't have to first download the sources? For my workflow (developer of software depending on Ipopt and therefore mumps), this is better because I don't have to wait for the download on every fresh cmake configuration step and work with git submodules instead.

I very much like the ease of use of your CMake files and therefore I wonder: Have you considered mirroring MUMPS here on github or do you know of any other git mirror?

[scivision]

I don't know of any MUMPS source Git mirror. The MUMPS website requests each user register via email. However, via discussion with MUMPS authors, they approved my CMake method of downloading from their servers. I imagine this allows them to track general MUMPS popularity to help justify their funding by counting downloads from their server.

Another reason is that I have several such packages I make CMake builds for, and for which I use a similar FetchContent to download source. It would be too many combinations for me to maintain across libraries and versions.

A possible alternative is to allow the user to specify a local archive file, or have CMake itself cache the archive file, outside the build directory. This would avoid the redownloading for every fresh build directory.

[scivision]

The way I'm thinking of implementing this is a directory under my CMake-Mumps top-level directory that caches Mumps source archives.

[eike-fokken]

Unfortunately I don't have much knowledge of CMake and couldn't help with implementing that but it sounds very useful!

[eike-fokken]

This seems relevant, I guess?
https://gitlab.kitware.com/cmake/cmake/-/issues/20536

Sounds like there is already functionality to store the fetched content somewhere else.

[scivision]

I think this does what you want, the latest main branch changed in cb5adab

The source is now cached per MUMPS version, and doesn't need to re-download for new build directory.

[scivision]

This could be improved by having an optional variable that would allow top-level CMake projects consuming MUMPS via FetchContent or ExternalProject cache at the top-level project. Otherwise, the MUMPS cache would still be implicitly deleted

[eike-fokken]

I can confirm that the cache works. But your last point is the use case I'm interested in.
For me this sounds like a feature request for cmake itself.
I think it would be nice if cmake would advertise a cache directory in which every fetchcontent call is allowed to store things.
Maybe I'll create an issue with cmake, I'll leave a link here if I get to it.

[eike-fokken]

Nevermind.
I just learned enough about fetchcontent to satisfy my needs here:
Unless some subproject decides to use a non-standard path, all fetched content should be placed inside
<CMake_BINARY_DIR>/_deps

so instead of killing the whole binary dir I just kill everything but _deps and should be good to go. For my usecase I don't expect to be running multiple versions of mumps in parallel so that's enough for me.
I still like using git submodules better but that's on me.