search

conda-forge / osqp-feedstock

A conda-smithy repository for osqp.
BSD 3-Clause "New" or "Revised" License
0 stars 13 forks source link

osqp c library #25

Closed traversaro closed 3 years ago

traversaro commented 3 years ago

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:

h-vetinari commented 3 years ago

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

There's substantial prior art on this, cf. https://github.com/conda-forge/conda-forge.github.io/issues/1073.

My preference would be:

Ping @conda-forge/osqp

traversaro commented 3 years ago

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 (https://github.com/oxfordcontrol/osqp/commit/027d4d696e0d65ad8bb6e1a41efdd17e391ef134), 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 commented 3 years ago

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 https://github.com/conda-forge/conda-forge.github.io/issues/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 commented 3 years ago

@isuruf made an interesting comment in https://github.com/conda-forge/scs-feedstock/issues/18#issuecomment-753382409, 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 https://github.com/conda-forge/osqp-feedstock/issues/25#issuecomment-743985562, 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 commented 3 years ago

[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 commented 3 years ago

Perfect, thanks!

h-vetinari commented 3 years ago

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

traversaro commented 3 years ago

Given that the actionable problems are tracked in https://github.com/conda-forge/osqp-feedstock/issues/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 commented 3 years ago

Sure, then this issue can be closed.