Closed traversaro closed 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:
libosqp
Ping @conda-forge/osqp
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?
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
.
@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 ?
[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).
Perfect, thanks!
@traversaro, can we make this feestock depend on libosqp
? Would you mind sending a PR? 🙃
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.
Sure, then this issue can be closed.
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:
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 thenosqp-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.osqp
package with python bindings, and theosqp-c
for the C shared library.