[WIP] Depend on libosqp

[traversaro]

Work in progress to fix #35 .

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-linter]

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.

[h-vetinari]

Thanks for tackling this! Your patch isn't quite functional yet, it seems...

[h-vetinari]

@bstellato @gbanjac
After discussion in #25, the proposal is to depend on a separately built libosqp, not least since the releases upstream are also not necessarily in sync.

What do you think about the approach, and would you be willing to accept a patch upstream for using an "external" osqp like @traversaro is preparing in this PR?

[traversaro]

@bstellato @gbanjac
After discussion in #25, the proposal is to depend on a separately built libosqp, not least since the releases upstream are also not necessarily in sync.

What do you think about the approach, and would you be willing to accept a patch upstream for using an "external" osqp like @traversaro is preparing in this PR?

To clarify, the osqp and qdldl sources would still be necessary to support codegen, it just the Python extension on its own that will be linking an external shared osqp library provided by the libosqp package.

Thanks for tackling this! Your patch isn't quite functional yet, it seems...

Yes, I am still working on it, I don't have a lot of experience with setup.py-based builds, so I need to learn on the fly. : )