[LinearSolver.Direct] Fix metis dependency

[olivier-roussel]

Continuation of #4266

As required by conda-forge/staged-recipes#23085, we must avoid static libraries to comply conda-forge rules.
Tests with more recent versions of metis (such as one available on conda-forge) seems to introduce some bugs (@bakpaul @alxbilger Do you have some inputs to provide here ?).
For now, the solution we converged to is to dynamically link metis with Sofa.

---

By submitting this pull request, I acknowledge that
I have read, understand, and agree SOFA Developer Certificate of Origin (DCO).

---

Reviewers will merge this pull-request only if

• it builds with SUCCESS for all platforms on the CI.
• it does not generate new warnings.
• it does not generate new unit test failures.
• it does not generate new scene test failures.
• it does not break API compatibility.
• it is more than 1 week old (or has fast-merge label).

[alxbilger]

Yes, I don't have the exact commit but, after the version 5.1.0, some changes lead to a crash. Before the changes, it works.
It has been fixed later in this commit: KarypisLab/METIS@36262ad. It means the versions in between both commits cannot be used without a crash.

Note also that the version number (in the code) has not been updated properly along the history of the repository: KarypisLab/METIS@f5ae915. It went from 5.1.0 to 5.2.1, whereas there is a 5.1.1 release.

Finally, less importantly, in SOFA we need a portable random generator in METIS for reproductible results. It is enabled via a compilation option METIS-GKLIB_GKRAND. This is not enabled by default in releases.

[fredroy]

[ci-build][with-all-tests]

[olivier-roussel]

The bug introduced in metis somewhere between v5.1.0 and v5.2.1 looks similar to conda-forge/gtsam-feedstock#21.
As it is fixed in v5.2.1, we should probably wait that this version comes in conda forge, there is a quite recent and active PR on this: conda-forge/metis-feedstock#41.

[olivier-roussel]

@bakpaul This would mean that you don't need to port v5.1.0 branch on your fork, we would rely on v5.2.1 both for external package (including conda) and for the fetch of your fork, which already has a v5.2.1 branch.

[olivier-roussel]

@bakpaul I'm afraid the current PR to have a metis 5.2.1 package on conda-forge (conda-forge/metis-feedstock#41) is stalling... and as the official repository is not active anymore (PR not merged anymore neither) and the official build chain is broken, it can take a lot of time before a 5.2.1 comes up on conda-forge.
I think we would better be safe and ensure that we have a working solution, so we would need you to backport the changes of your metis fork on the 5.1.0 branch, in order to have a consistent version of used metis, wether it's external or fetched dependency.

[bakpaul]

I've added the v5.1.0-ModernInstall branch to our fork. Actually this code wasn't on the repo itself so I just copied the files presents in SOFA and added my CMake configuration files. It compiles, you can try to add the find or fetch mechanism using this

[alxbilger]

Do you want to message or not? If not, please remove this line

[bakpaul]

We will also need to install metis library to distribute it with the binaries. I didn't have time to make it work, I'll try tomorrow.

[bakpaul]

[ci-build][with-all-tests][force-full-build]

[bakpaul]

So now the linkage of metis is PRIVATE in Sofa.Component.LinearSolver.Direct and every other target requiring metis finds the package itself (e.g. SofaMatrix) .

One problem is that FetchContent_MakeAvailable make the target available for the current target and its child (that is why the test in Sofa.Component.LinearSolver.Direct is able to link to metis without the need of finding it) but other unrelated targets cannot find it. So we cannot keep it Public because it will not be found by the other target linking to Sofa.Component.LinearSolver.Direct because a lot of them doesn't require metis

[fredroy]

Looks fine to me otherwise 🤷‍♂️