Create -devel and -static variants

[adriendelsalle]

Description

Convert this feedstock into a multi-output recipe:

• sundials: ships shared libraries
• sundials-devel: variant to expose static libs (and shared ones) to allow developers selecting the variants they need
• sundials-static: ships static libraries

fix superlu_mt vendoring (install the lib and headers in the host prefix)
remove unused patch

Fixes #102
I still need to test this on Windows to see to make the appropriate changes

I also need to add the superlu_mt license

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[traversaro]

Just a curiosity, why you choose to call the static variant with -devel suffix instead of -static as suggested in CFEP-018 (https://github.com/conda-forge/cfep/blob/main/cfep-18.md)?

[adriendelsalle]

Hi!

• I didn't knew about this :)
• I saw few packages with -static suffix, such avec yaml-cpp, indicating that only the static lib(s) are packaged in this variant. Here I would like to provide both static and shared lib(s) to make it possible to build both variants of your downstream project without having to change the env (as it's the case for yaml-cpp because libraries can't be built together, they are identified by the same target). sundials made it possible to by carefully defining static and shared variants with different targets etc.
• I also took inspiration from boost-devel recipe

From the CFEP-18, it looks like we should also convert the win-64 package to expose shared libs (because it's possible, and somehow desirable and more consistent across platforms). But the it may break current usage, so for now I stick with the past choices

[traversaro]

Ok, I got it, so installing -devel can be used to link both shared or static, given how sundials defines CMake imported targets, that is clear, thanks!

[adriendelsalle]

I just packaged the superlu_mt license.

The Windows package is building successfully providing a small fix upstream, also tracked as an issue and an associated PR.
I propose to build both static and shared libs variants in sundials and sundials-devel, and later remove the static libs from sundials if it's best pratice. I don't know how to make a deprecation warning to avoid breaking users.

Ready for review @traversaro @jschueller @bjodah

[jschueller]

building static+shared does not follow the conda-forge standards, a sundials-static with only static libs would be ok though

[adriendelsalle]

hi @jschueller

Where is this mentioned?
I agree that for a runtime package it's wasting space to ship static libs, but for a development package it avoids the boilerplate of having 2 separate envs to build variants of downstream packages. It's the eternal dilemma between source vs binaries distribution when multiple variants can be produced.

I can surely add another sundials-static output.

Is this a no-go from your perspective?
I would prefer to keep all recipes concerning sundials in the same repo instead of building another feedstock

[adriendelsalle]

@conda-forge/help-c-cpp any advice about this discussion ?

[xhochy]

You should add a separate package -static that contains the static library. This should be explicitly pulled in if you want the static library, not automatically as part of -devel. This is a bit different in the boost case as some things in the boost world are static only. Otherwise, we really want to have -devel be "what you need to compile against this lib" and -static "I really want to link against the static library".

[adriendelsalle]

Thanks for the quick feedback!

You should add a separate package -static that contains the static library.

I agree, a -static output should only ship static libs. I'll add it as an extra output.

Otherwise, we really want to have -devel be "what you need to compile against this lib" and -static "I really want to link against the static library".

I don't get from your answer if having a -devel variant is OK @xhochy ?

I'll fix the build scripts concerning superlu_mt

[xhochy]

I don't get from your answer if having a -devel variant is OK @xhochy ?

What is the use case for the -devel variant here? From the build scripts, it seems, it contains the same as the non-devel one.

[adriendelsalle]

I answered the same question few lines above :): #103 (comment)

it contains the same as the non-devel one.

On Windows yes, because @jschueller built the recipe with Windows shipping static libs and Linux shipping shared ones. I didn't wanted to break projects relying on Windows package shipping statics.. and don't know about deprecating this package in favor of a -static one but definitely I would prefer this option.

On linux, sundials only ships shared libs and sundials-devel ships both static and shared libs. I'll add sundials-static to ship static libs only.

[jschueller]

its ok to remove static libs because users should not expect them outside static packages

[adriendelsalle]

@jschueller @xhochy your recommendations have been followed. Ready for review!

[adriendelsalle]

@jschueller is it OK for you?

[adriendelsalle]

@xhochy I would like to make this available asap, what's the process when there is no answer from feedstock maintainers? Thanks!

[adriendelsalle]

@conda-forge/help-c-cpp

[xhochy]

@jschueller bump.

[adriendelsalle]

Thanks!