search

spack / spack

A flexible package manager that supports multiple versions, configurations, platforms, and compilers.
https://spack.io
Other
4.28k stars 2.27k forks source link

CoinHSL: Support the Meson build system #43610

Closed AndrewLister-STFC closed 5 months ago

AndrewLister-STFC commented 6 months ago

The current recipe for CoinHSL is outdated and only supports versions that are no longer available to download. This PR adds support for the Meson build system that newer versions require while maintaining backwards compatibility.

There are 2 types of version for CoinHSL, a partial version (referred to as "archive") with reduced support but less restrictive licence, and a full version. The archive version has no dependencies, although I'm not sure how best to capture that in the recipe.

Q by @AndrewLister-STFC: Any suggestions on the best way to define a different set of dependencies for the archive and full versions? A by @bernhardkaindl: It is possible to set different dependencies with when:

    depends_on("dependency1", when="@:2.21")  # Versions up to 2.21 get dependency1
    depends_on("dependency2", when="@2.22:")  # Versions since 2.22 get dependency2

Does this answer your question?

bernhardkaindl commented 5 months ago

@AndrewLister-STFC

Any suggestions on the best way to define a different set of dependencies for the archive and full versions?

It is possible to set different dependencies with when:

    depends_on("dependency1", when="@:2.21")  # Versions up to 2.21 get dependency1
    depends_on("dependency2", when="@2.22:")  # Versions since 2.22 get dependency2

Does this answer your question?

AndrewLister-STFC commented 5 months ago

@AndrewLister-STFC

Any suggestions on the best way to define a different set of dependencies for the archive and full versions?

It is possible to set different dependencies with when:

    depends_on("dependency1", when="@:2.21")  # Versions up to 2.21 get dependency1
    depends_on("dependency2", when="@2.22:")  # Versions since 2.22 get dependency2

Does this answer your question?

I ended up using something like this, although I now have a very odd versioning scheme to accommodate it:

archive-2023.11.17
archive-...
2014.01.10 -\
2014.01.17  |
2015.06.23  |- legacy builds (on autotools)
2019.05.21 -/
2023.11.17
...

Anything before "b" or after "2022" can use meson, anything before "b" doesn't need any deps, anything after "2022" has deps (blas, lapack, metis). The legacy autotools build that was already in the recipe is in the middle.

Ideally this would be in a different order but all I could find was operations on the ranges. I'd like the order to be:

2014.01.10 -\
2014.01.17  |
2015.06.23  |- legacy builds (on autotools)
2019.05.21 -/
2023.11.17-archive
2023.11.17
...

Having tested this, we've found an issue in the meson build system with the libmetis_path argument. I'll have to put in a new release and skip some versions in the spack recipe to make it work with the spack location of metis. I should have some time to work on this next week.

AndrewLister-STFC commented 5 months ago

I can rebase and squash the commits on this if that's preferred for the repo