release ocaml-rocksdb-0.02 #27360
release ocaml-rocksdb-0.02 #27360
Conversation
This ocaml-rocksdb interface is built using cppffigen, a tool that generates OCaml FFI bindings to C++ libraries that follow the Google C++ Style Guide for memory-ownership.
chetmurthy
force-pushed
the
release-ocaml-rocksdb-0.02
branch
from
5440587 to
9c78ce6
Compare
| "--personality=i686-w64-mingw32" {os = "win32" & os-distribution = "cygwin" & host-arch-x86_32:installed} | ||
| "--personality=x86_64-w64-mingw32" {os = "win32" & os-distribution = "cygwin" & host-arch-x86_64:installed} | ||
| "pkg-config" {os != "win32" | os-distribution != "cygwin"} | ||
| "--atleast-version=7.8.3" "rocksdb"] { |
There was a problem hiding this comment.
is this 7.8.3 constant correct? what's its relation to the "ge-5-17-2" aim?
| !(os-distribution = "ubuntu" & (os-version = "20.04" | os-version = "22.04")) | ||
| } | ||
| ] | ||
| synopsis: "Virtual package relying on a system installation of RocksDB (version >= 5.17.2)" |
There was a problem hiding this comment.
I understand the need for this kind of package, and I wish we had a good solution (or at least a standard solution) to offer but right nnow it's an unsolved problem for the opam repo.
I'm not very happy with adding version constraints as part of the name of a package. Although I can see how it's needed and how we can't reasonably generate conf-rocksdb packages for each available version of rocksdb. Or maybe that's reasonable but would require having a separate dedicate opam repository.
Anyway… Anyone has ideas?
Otherwise I guess we can possibly merge for now and possibly revisit.
There was a problem hiding this comment.
It's actually worse and worse. When I started with trying to get this to work, I foolishly assumed that pkg-config would be available to check rocksdb's package-version. But (haha, silly me) that wasn't the case with these older versions of rocksdb like (sigh) current Debian (11, 12) and backlevel Ubuntu (20.24, 22.04). And they were all backlevel versions of Rocksdb (5.17.2, 6.11.4). Other platforms had 7.8.3, though a few even failed the check.
I could put these changes into conf-rocksdb ?
The bigger problem of not being able to state version-constraints is .... painful. Some packages (like Rocksdb) appear to be changing their API pretty rapidly. But OTOH this is a big change to opam, and I sure think there are better ways to spend developer resource than on this.
There was a problem hiding this comment.
I think that we can accept the ge-… name for now
And maybe someone with time available can write a generator for many conf-packages where the version number is just substituted.
| @@ -0,0 +1,59 @@ | |||
|
|
|||
There was a problem hiding this comment.
Normally we avoid having ocaml as part of the name of packages. See https://github.com/ocaml/opam-repository/tree/master/governance/policies#7-new-package-names-should-avoid-the-ocaml-prefixsuffix
I don't think this porject necessarily needs an exception. (Unless you can make a case for it?)
There was a problem hiding this comment.
I'm happy to make it "rocksdb" ? Or any other name you would propose grin.
|
Quite a few failing CI checks here on various platforms. Sounds like we'll need investigation there, in addition to the naming question. Marking this accordingly. |
This ocaml-rocksdb interface is built using cppffigen, a tool that generates OCaml FFI bindings to C++ libraries that follow the Google C++ Style Guide for memory-ownership.
This might not be the best name for this package. There are already "orocksdb" and "ahrocksdb" packages (both based on ctypes); if you think this should be named something else, I'd be happy to change it.