Add SOFA supported plugins

[olivier-roussel]

This adds multiple packages for the officially supported plugins for SOFA by upstream. SOFA core package has been recently merged and is already available on CF. The initial staged-recipes PR which was containing both SOFA core and plugins has been splitted, and this PR is the second part for the supported plugins, updated since it has been initiated more than 2 years ago.
Most of these packages have inter-dependencies so they are submitted in this one single PR. Sorry, it makes it quite big, but at least these recipes are mostly similar. IMO, the only case that deserves particular attention is sofa-glfw (see below).
Here are the included packages:

• sofa-python3: SOFA plugin - Python bindings for SOFA core & Python scene description support
• sofa-modelorderreduction: SOFA plugin - Plugin to reduce models. C++ with Python bindings.
• sofa-beamadapter: SOFA plugin - Kirchhoff rods to simulate any 1D flexible structure. C++ library.
• sofa-stlib: SOFA plugin - SOFA Template Library containing SOFA scenes templates. Python only.
• sofa-cosserat: SOFA plugin - Plugin to simulate linear structures using Cosserat theory. C++ with Python bindings.
• sofa-softrobots: SOFA plugin - Components & method for soft robotics. C++ with Python bindings.
• sofa-softrobotsinverse: SOFA plugin - Inverse control method for soft robotics. C++ with Python bindings.
• sofa-glfw: SOFA plugin - Quick and simple GUI for SOFA, based on GLFW and Dear ImGui. C++ with Python bindings.
• sofa-app: GUI executable based on sofa-glfw plugin

Special notes for sofa-glfw:
This plugin does vendor some code, which is not redistributed in the package, only used at compile-time. We could not find a satisfactory solution for the imgui vendored code. This is because imgui upstream have made the choice to manage two versions (through two branches) of imgui: master and docking (which contains some advanced features). Current imgui conda package does not include the docking version, and sofa-glfw is using this docking branch at relies on its Docking advanced features. As already discussed with imgui conda package maintainers (conda-forge/imgui-feedstock#22), keeping vendoring code here may sound reasonable in such case, due to the lack of alternatives.
Other vendored dependencies in sofa-glfw are:

• ImPlot: https://github.com/epezent/implot: Conda-forge package of implot exists but it relies on imgui package, which is the master branch version of imgui, and not the docking one we need (as explained above).
• IconFontCppHeaders: https://github.com/juliettef/IconFontCppHeaders (header only)
• SimpleIni: https://github.com/brofield/simpleini (header only). Note that a PR is open on staged recipes : Add simpleini recipe #31757.
  Licenses have been included to the package.

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[conda-forge-admin]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/sofa-softrobots/recipe.yaml, recipes/sofa-beamadapter/recipe.yaml, recipes/sofa-app/recipe.yaml, recipes/sofa-glfw/recipe.yaml, recipes/sofa-python3/recipe.yaml, recipes/sofa-cosserat/recipe.yaml, recipes/sofa-modelorderreduction/recipe.yaml, recipes/sofa-stlib/recipe.yaml, recipes/sofa-softrobotsinverse/recipe.yaml) and found some lint.

Here's what I've got...

For recipes/sofa-app/recipe.yaml:

• ❌ There are too few lines. There should be one empty line at the end of the file.

For recipes/sofa-glfw/recipe.yaml:

• ❌ If python is a host requirement, it should be a run requirement.

For recipes/sofa-stlib/recipe.yaml:

• ❌ There are 1 too many lines. There should be one empty line at the end of the file.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/20899426208. Examine the logs at this URL for more detail.}

[github-actions]

Hi! This is the staged-recipes linter and I found some lint.

File-specific lints and/or hints:

• recipes/sofa-cosserat/recipe.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: hugtalbot. Please ask them to comment on this PR if they are.

• recipes/sofa-glfw/recipe.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: hugtalbot. Please ask them to comment on this PR if they are.

• recipes/sofa-stlib/recipe.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: hugtalbot. Please ask them to comment on this PR if they are.

• recipes/sofa-python3/recipe.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: hugtalbot. Please ask them to comment on this PR if they are.

• recipes/sofa-beamadapter/recipe.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: hugtalbot. Please ask them to comment on this PR if they are.

• recipes/sofa-modelorderreduction/recipe.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: hugtalbot. Please ask them to comment on this PR if they are.

• recipes/sofa-app/recipe.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: hugtalbot. Please ask them to comment on this PR if they are.

• recipes/sofa-softrobotsinverse/recipe.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: hugtalbot. Please ask them to comment on this PR if they are.

• recipes/sofa-softrobots/recipe.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: hugtalbot. Please ask them to comment on this PR if they are.

[bakpaul]

I want to be a co-maintainer of this package.

[hugtalbot]

So do I

[github-actions]

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

[conda-forge-admin]

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 (recipes/sofa-softrobotsinverse/recipe.yaml, recipes/sofa-softrobots/recipe.yaml, recipes/sofa-modelorderreduction/recipe.yaml, recipes/sofa-app/recipe.yaml, recipes/sofa-stlib/recipe.yaml, recipes/sofa-cosserat/recipe.yaml, recipes/sofa-python3/recipe.yaml, recipes/sofa-beamadapter/recipe.yaml, recipes/sofa-glfw/recipe.yaml) and found it was in an excellent condition.

[olivier-roussel]

@conda-forge/help-c-cpp @conda-forge/help-python this is ready for review

[olivier-roussel]

Bumping, if anybody has a bit of time to review / merge this, would be huge help ! Thanks !
@conda-forge-admin please ping conda-forge/help-c-cpp

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-webservice.

I was asked to ping @conda-forge/help-c-cpp and so here I am doing that.

[olivier-roussel]

@conda-forge/help-c-cpp Could someone review / merge this ? I know the PR is quite big... Thanks a lot for those who will have time for it

[danielnachun]

It may take a bit to review all of this but two things to start:

• Check my suggestions for Add simpleini recipe #31757 on how to call cmake without have to create or change to any directories. You can use a directory name for -B argument other than build if that already exists.
• For the third party packages other than simpleini, which already has a PR, can these also have recipes created? Ideally we would fully devendor here, although if a library is header-only and too much patching is required, we may be better of vendoring.

[olivier-roussel]

Thanks so much for your review @danielnachun.
To answer to your first two points:

• CMake calls in build scripts have been modified according to your remarks
• Apart from simpleini, the two other vendored library are imgui and IconFontCppHeaders (see PR description for more details). I totally understand why we should as much as possible fully unvendor, but I'm afraid that we can't unvendor these three libraries for the following reasons:
  • imgui : upstream is maintaining two parallel branches, main and docking, which are both released. Docking has more advanced features (see https://github.com/ocornut/imgui/wiki/Docking), but has a slightly different API. There is already a CF package but for main only. We already discussed in Add docking variant imgui-feedstock#22 that unfortunately we have no real solution to package this imgui docking as is in CF. Upstream mentioned that his goal is to have both branches that converge at some point and only one release.
  • implot: there is already a package on CF, but it depends on imgui package, which is in the main and not docking version. So we can't use it.
  • IconFontCppHeaders: there is no package yet on CF, it is a set of headers for font resources. It is usually purely vendored, as there is no CMake or equivalent. We could add a recipe for it by adding a CMake support, but to me the main blocking point is that there is no release or even version of the software on the github repository.
    So I'm afraid we can't go further for these three vendored library, even not adding a recipe for them.

[olivier-roussel]

The CI is failing as it looks like there is a multi-recipe build order resolution bug in rattler-build. It outputs to build sofa-app first, which depends on sofa-python3 and sofa-glfw within this recipe, but it fails as they have not been built yet.
I could reproduce the bug locally.
I hope I'll have some time to reproduce to a minimal reproducible example to submit an issue on rattler if confirmed.

[olivier-roussel]

Locally, I reproduce the bug of bad build order for multi-recipe using rattler-build==0.58.4, but not with rattler-build==0.59, which looks pretty weird. Let's wait rattler-build==0.59 to be sync with staged-recipes and retry.
FYI @wolfv

[olivier-roussel]

Now it is running fine with rattler-build==0.59

[danielnachun]

Thanks so much for your review @danielnachun. To answer to your first two points:

• CMake calls in build scripts have been modified according to your remarks

• Apart from simpleini, the two other vendored library are imgui and IconFontCppHeaders (see PR description for more details). I totally understand why we should as much as possible fully unvendor, but I'm afraid that we can't unvendor these three libraries for the following reasons:

  • imgui : upstream is maintaining two parallel branches, main and docking, which are both released. Docking has more advanced features (see Wiki: Docking (ocornut/imgui)), but has a slightly different API. There is already a CF package but for main only. We already discussed in Add docking variant imgui-feedstock#22 that unfortunately we have no real solution to package this imgui docking as is in CF. Upstream mentioned that his goal is to have both branches that converge at some point and only one release.
  • implot: there is already a package on CF, but it depends on imgui package, which is in the main and not docking version. So we can't use it.
  • IconFontCppHeaders: there is no package yet on CF, it is a set of headers for font resources. It is usually purely vendored, as there is no CMake or equivalent. We could add a recipe for it by adding a CMake support, but to me the main blocking point is that there is no release or even version of the software on the github repository.
    So I'm afraid we can't go further for these three vendored library, even not adding a recipe for them.

Thanks for the careful explanation, these are indeed blockers to unvendoring. It sounds like for imgui and implot there is some hope that when the branch merge happens it can be devendored. IconFontCppHeaders is much less of a concern in terms of vendoring being header-only. The only challenge we occasionally encounter is if the code becomes too old and doesn't work with newer compilers. Hopefully that doesn't come up any time soon.

[traversaro]

Thanks a lot @olivier-roussel @bakpaul @hugtalbot , and sorry for the delay in the review. The PR seems fine for me, it is ok for me to rebase the branch on top of latest main, or you want to do it yourself?

[olivier-roussel]

@traversaro Thanks a lot for your review ! I've just updated the branch, let's wait for the CI