C interface

[lovasoa]

Hello,
Feel free to close this if this is out of scope for this project.
I started working on a C interface for OSI: https://github.com/lovasoa/c-osi
What would you think about having an official C interface ? This would make it easier to write solver-independant code, to switch solvers at runtime, and to interact with solvers from languages other than C++.

[tkralphs]

It feels a bit funny to have a C interface for what is essentially a C++ interface that wraps other C interfaces :). I guess it might make more sense to have the C interface be native and then to wrap that native C interface to get a C++ one. Putting that aside, this seems like it could be useful, although this is the first time it's come up. All in all, I think if you wanted to build a C interface, it would be a welcome contribution to this project.

[lovasoa]

Did you have a look at the C interface I defined in https://github.com/lovasoa/c-osi ? (it's mostly taken from cbc). Would it be okay to upstream that and distribute "official" mutually-compatible libosicbc.so, libosiglpk.so, libosilazygurobi.so, and so on ?

[tkralphs]

I did have a look. One comment right off the bat would be that since I think this is pretty clearly a derivative work, you should probably leave the copyright statements intact (or perhaps assert joint copyright if you think it is merited). It is always nice to acknowledge the original author(s) and point people directly to the original version. Maybe you were planning to do that already.

I'm not sure what you mean by "would it be OK to upstream that." If you mean contribute it back to coin-or/Osi, then sure, I think it would be a welcome contribution.

As for distributing libraries, that is a can of worms because of licensing issues, but we could discuss it. If you're after libraries for Linux, I guess you know what's involved there. We're building universal static binaries for Cbc and we could probably adapt that process for Osi as well. So far, our process has been to upload binaries to Bintray and I want to keep the process uniform across all projects in the Optimization Suite, as I'm maintaining a lot of them. In the long-run, I would be happy to entertain a move to Github Actions and to upload artifacts to Github itself.

Let me know if this answers your question!

[lovasoa]

I think this is pretty clearly a derivative work, you should probably leave the copyright statements intact (or perhaps assert joint copyright if you think it is merited). It is always nice to acknowledge the original author(s) and point people directly to the original version. Maybe you were planning to do that already.

Yes, you're right ! I quickly hacked something together, copy-pasting functions. I just copied the header copyright comment from cbc too.

I'm not sure what you mean by "would it be OK to upstream that." If you mean contribute it back to coin-or/Osi, then sure, I think it would be a welcome contribution.

Great, I'll open a PR ! How should this be handled in the Osi repo ?
I currently have some preprocessor magic to include a different solver based on a #define : https://github.com/lovasoa/c-osi/blob/main/osi.cpp#L9-L18

How would you like this to be handled in coin-or projects ? Should we keep the define, and let each project that depends on Osi update their build system to set the variable appropriately to compile their own libosi ?

As for distributing libraries [...] we could discuss it.

What I would love is for a completely foss osi library to be distributed by linux distributions, so that I can just

sudo apt install coinor-libosi-dev
gcc mycode.c -losi

then distribute a binary, and let users just download a different libosi.so (from bintray for instance, potentially with a non-free license) if they want to use a different solver.

Do you think this is an achievable goal ?

[tkralphs]

Sorry for the delay. I'm not sure of the best way to accomplish this. Now that I'm thinking about it, it looks a little tricky. At the moment, available solvers are detected at compile time. To do what you want, it appears that you need something like what was attempted with the lazylpsolverlibs project referenced in the README. I think you would first need to resurrect that project. I'm not sure exactly how to deal with supporting different version of lazily loaded libraries. Anyway, it looks doable, but also non-trivial. I probably couldn't contribute much, but maybe some others who work on Osi could chime in.

[lovasoa]

I think there is a misunderstanding. I don't want to create anything like lazysolverlibs (which detects if a solver is available at runtime and dynamically loads its library with dlopen). What I want is to distribute a very classic binary with dynamic linking (like all binaries distributed in linux distributions). There is no magic there, the binary just declares that it depends on libosi and we let the operating system load it like it does with any other library. But we can still have multiple libosi.so files that all implement the same interface and that are all ABI compatible between themselves. This is what I implemented in the repo I linked above.

If someone is interested, they could implement that interface for lazysolverlibs, but this is a different discussion.