Closed edwintorok closed 8 years ago
Definitely!
As I was developing the library trying to spread outward and have lots of features was a high priority (hence ocephes
and calling out to lbfgs
, lacaml
), but certainly refining those implementations where it makes sense is a good idea. Ideally, I imagine an oml_lite
(probably a better name is still to be determined) that has a similar outline (hierarchy of modules and capabilities) but with different implementations. I don't really have the bandwith for this issue at the moment but a PR would be very welcome!
@edwintorok I believe that #171 addresses this issue. I'll add oml_lite
as a package to opam soon.
If I just want to use a few simple modules from
Oml
(e.g.src/lib/stats
) I may not want to depend/install additional C libraries, e.g. I may want to use them withjs_of_ocaml
. OTOH if I want to use more complex modules from Oml then depending on C libraries makes sense for speed. Would you be interested in splitting the omlocamlfind
package into subpackages (roughly around the way its already split per directories insrc/lib
) and have the subpackages depend only on things they really need? Then the opam file could be made conditional too.