osqp c library

[traversaro]

• I read the conda-forge documentation and could not find the solution for my problem there.

Hi @conda-forge/osqp ! I am interested in providing the osqp C library in conda-forge, in a form that can be consumed by C and C++ project. At the moment this feedstock just installs the Python bindings of OSQP by statically linking the Python bindings with OSQP, and so the resulting library is not available to downstream C or C++ projects. I would be curious on your opinion regarding how to achieve this.

A few of the (many) possible options are:

• Create a completely separate osqp-c feedstock that just installs the osqp library to be consumed by C/C++ projects. This is probably the easiest option, even if it could create problems if then osqp-c provided shared library is linked in a C/C++ library that is loaded via some form of Python bindings, and the Python bindings load also the Python bindings provided by this feedstock, that could have a different ABI.
• Modify this feedstock to install both Python bindings and the C shared library, and make sure that the Python bindings link the C shared library instead of the static one.
• Like the previous option, but splitting the produced packages in the osqp package with python bindings, and the osqp-c for the C shared library.

[h-vetinari]

Hey @traversaro, thanks for opening this issue. :)

There's substantial prior art on this, cf. conda-forge/conda-forge.github.io#1073.

My preference would be:

• turn this feedstock into a multi-output recipe
• add an output for libosqp

Ping @conda-forge/osqp

[traversaro]

Thanks @h-vetinari for the quick feedback.

I agree with your preference. I started checking out the situation, and it appears that the
osqp-python's interface setup.py currently hardcodes the use of the manually build static osqp library, so that part will need a patch.
Furthermore the python osqp release v0.6.1 (the one current shipped by this package) osqp git submodule is actually pointing to an unreleased commit of osqp (osqp/osqp@027d4d6), that is not even part of the osqp's master branch, but rather of the branch https://github.com/oxfordcontrol/osqp/tree/develop-0.x .

For this reason, it may not be straightforward to add a libosqp output that contains a shared library that is used also by the osqp python package. For the time being, could it make sense to just add a libosqp output that just builds the v0.6.0 shared library, and leave the osqp package to use its own static version of osqp?

[traversaro]

Given the situation outline in the previous comment, I would first add to this feedstock a libosqp output that builds the osqp C shared library, and then make sure that the Python bindings use this shared library once upstream Python bindings use a release version of osqp. However, I have a doubt. In conda-forge/conda-forge.github.io#1073 it does not seem that a consensus of the naming of C libraries was reached, so I wanted to double check that for this feedstock maintainers libosqp is preferred over osqp-c.

[traversaro]

@isuruf made an interesting comment in conda-forge/scs-feedstock#18 (comment), that apply even more in this case as the release schedule of osqp-python has releases, such as the last one 0.6.1 that as mentioned in #25 (comment), does not correspond to any osqp release.
Given this, @h-vetinari do you still prefer the multi-ouput recipe or you are inclined to have a separate recipe for libosqp ?

[h-vetinari]

[I can answer effectively the same as for scs ;-) ]

Sounds good to me.

@traversaro, how do you feel about opening an addition for libosqp to https://github.com/conda-forge/staged-recipes? You can also add me as a maintainer, if you want (and ping me, if you need help).

[traversaro]

Perfect, thanks!

[h-vetinari]

@traversaro, can we make this feestock depend on libosqp? Would you mind sending a PR? 🙃

[traversaro]

Given that the actionable problems are tracked in #35, I think we can close this issue, what do you think @h-vetinari ? I opened that as it is more easy to track it for me if an issue has a clear description on what needs to be done.

[h-vetinari]

Sure, then this issue can be closed.