Add metis/5.1.1

[Nekto89]

Specify library name and version: metis/5.1.1

Closes #1152

---

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the
  conan-center hook activated.

[Nekto89]

@SpaceIm Is it crucial to rewrite this without new tools?

[SpaceIm]

@SpaceIm Is it crucial to rewrite this without new tools?

I think it's premature for CCI.

/cc @memsharded @lasote @SSE4 @uilianries @czoido

[jgsogo]

IMHO, the only issue would be some future Conan v1.x release breaking the syntax of these new tools/helpers. For these tools I wouldn't expect breaking changes (It is not a problem if, for some reason, they change the implementation (some new flag), following PRs will keep working, no unexpected errors or hard to fix ones).

At some point in time, we need to start using them... maybe the time has come? Of course, I wouldn't force the migration yet, but if the PR is already contributed using Conan v2 compatible features... for me it's ok, I don't see a blocker.

Edit.- For really common libraries I would try to delay these changes a little bit more, so those recipes keep working with a wider range of Conan versions (not just >=1.43).

[SpaceIm]

The problem is that there are still issues in these new tools, they are not yet as robust as old ones for some key behaviors.
See, you had to patch CMake minimum version of upstream CMakeLists to ensure https://cmake.org/cmake/help/latest/policy/CMP0091.html policy, because CMakeToolchain doesn't yet force this policy, otherwise msvc runtime wouldn't have been honored.

Moreover, the rule was CMake >= 3.1 support in CI for the moment, now it requires 3.15 for sure with CMakeToolchain (even with the policy CMP0091 set to NEW, anybody trying to build with CMake <= 3.15 would have its msvc runtime not honored since CMakeToolchain doesn't try to replace MT/MD stuff in CMAKE_CXX_FLAGS and CMAKE_C_FLAGS, it was a feature of cmake generator through conan_basic_setup()).

I'm also wondering how robust new CMake helper is with compiler=Visual Studio, since it's the main target on Windows in CCI.

[jgsogo]

At some point in time, we need to start using these new tools and helpers for compatibility with v2, and Conan 1.44 is the version when we think we should try to start promoting this migration (now we are using 1.43.3 in CCI). It doesn't mean that we need to modify all recipes, not yet, but we should start to accept PRs with this new integration soon.

How can we proceed? We cannot add required_conan_version = ">=1.44.0" and CMake >= 3.15 to every recipe just because this issue in CMake/Conan with VS? That would block every other user that is using older versions of Conan for build-systems other than VS... and they don't care about this MT/MD issue.

IMHO it's more the pain for Linux/Mac users if they are forced to use 1.44.0 than for the subset of Windows users that will get this error while building the packages from sources. Upgrading Conan (to this month's release) might be a blocker for many users and companies. CMake 3.15 was released in July 2019, so it should be easier to upgrade if they are not already using that version.

I agree that we should try to do our best, and we should try to warn those users about this issue, but we cannot block the rest of consumers from using something that works just because one configuration fails unless you use a bleeding edge version (and you try to build from sources).

---

@Nekto89 , thanks for backporting the recipe, sure it is the best way to go.

[SpaceIm]

@jgsogo that's fair. Is there any other known issue in CMakeToolchain compared to cmake generator? The other one I see is that CMakeToolchain forces CMAKE_FIND_PACKAGE_PREFER_CONFIG ON, and it may have undesirable side effects in several recipes (a recipe depending on another recipe generating different targets in Find & config contents, while Find & config file names are the same). It should be removed.

We can indeed patch upstream CMakelists and add a TODO to remove it if conan min version is bumped to at least the version fixing vc runtime issue.

[Nekto89]

small change will be needed after #8994

[jgsogo]

@SpaceIm , we trust the team that is more focused on the Conan client development and try to help them to move forward as well. AFAIK, there is nothing blocking and there is some pressure towards using these new generators (and dedicate more and more resources in v2).

Anyway, if a recipe uses CMakeToolchain to build that's internal to that recipe. If a user consumes a reference using CMakeToolchain that's the decision of the user. Those things are decoupled. For the first one everything is under our control, if we decide to use CMakeToolchain in one recipe we will manage to make it work and path or not whatever is needed... and the second one is totally outside our control, how a recipe is consumed is not dictated by that recipe.

Of course, the more CMakeDeps and CMakeToolchain you see in recipes, the more you are tempted to use them to consume those recipes, but besides that feeling, those are independent events.

[conan-center-bot]

All green in build 8 (7ce1a8d271c1f22d1eabc30164d5c9d44bab2042):

• metis/5.1.1@:
  All packages built successfully! (All logs)

[prince-chrismc]

This patch is really big 😱 I understand what it's doing but it hard to say if it's correct

Have you considered opening a PR upstream to contribute back? that can help us verify the work + not have to repeate this in the future 🤞

[Nekto89]

It has been taken from closed PR
https://github.com/KarypisLab/METIS/pull/15/files

Does conan support rename in patches? With rename it will be smaller