search

ktahar / ocaml-lp

LP and MIP modeling in OCaml
MIT License
27 stars 1 forks source link

Bundle GLPK statically #3

Open Drup opened 2 years ago

Drup commented 2 years ago

I suggest bundling GLPK in the library, just like in ocaml-glpk. Relying on system C packages is troublesome in many ways, makes the building more complex, and doesn't guarantee the version of GLPK used. I don't think there are many reason to rely on separate linking here.

ktahar commented 2 years ago

I think ocaml-glpk also depends on system C package and bundling only GLPK's old API codes (ocaml-glpk/src/oldapi/lpx.c).

Do you mean I should include entire source tree of GLPK and configure to build it along with lp-glpk package? I think this leads to some complex configurations and increase build load of lp-glpk package.

Please correct if my understanding is wrong.

Drup commented 2 years ago

I though ocaml-glpk bundled the C package, but apparently I was mistaken.

In any case, it would probably be best adopt configuration similar to this: https://github.com/smimram/ocaml-glpk/blob/master/src/dune#L17 to avoid the user having to specify C link flags.

ktahar commented 2 years ago

Thanks. I think C link flag for user app is necessary now because I've used the pure OCaml interfacing (using foreign of ctypes). I have to dig more, but may cstub-generation of ctypes solve this problem? Give me some time to fix this.

ktahar commented 2 years ago

4 introduces stub-generation of ctypes and users don't have to specify C link flags now.

In addition, it got a bit more robust against possible diff of glpk.h.

But the build is dependent on system libglpk. Full-bundling might be possible too, but I'm not sure now if it's better in all aspects.