I’m in the process of porting a project from using oasis
to using jbuilder
as the build system. I manage to get things building so far, but I’m unsure how to check for correct versions of OCaml and dependencies. oasis
would generate configure.sh
file that would check dependencies, but there doesn’t seem to be a similar option for that from what I can tell from the docs. I know that jbuilder
can read a project.opam
file, but does it also infer version dependencies from it? If not, what is the best way to write a configure.sh
or something similar to do this?
Jbuilder doesn’t do this explicitly, since it’s increasingly better just to depend on opam
or the system packaging model to do that version checking.
There are two ways to get the right set of libraries for jbuilder to build:
-
opam install
everything, in which case your opam constraints will get the right source - clone a jbuilder workspace with your working set of packages in subdirectories, and do a
jbuilder build <target>
at the toplevel directory.
In the latter case, the batch-building means that version incompatibilities in whatever you have cloned become obvious fairly quickly. What I’ve been finding while working in the ‘workspace’ mode is that library versions are meaningless, since I typically iterate on interfaces quite fast. When I am ready to cut a release, I update the opam
files and cut individual library releases.
Therefore, I am of the opinion that jbuilder projects shouldnt do version checking – but rather delegate it to opam
.
I agree that handling version dependencies etc. is probably best being OPAM’s job. I think what I would like to see is an opam
subcommand that will read a given .opam
file, examine the current state of my opam
installation, and then notify me of what I need to install/upgrade to build the current project. opam install
has a --deps-only
option, but I think that only applies to packages that can be installed from an OPAM repo, and not a local file?
That sounds like a really good idea, and fits in well with the new local features in opam2. A feature request in Issues · ocaml/opam · GitHub would be appreciated.
No need to open an issue. This is already in v2, see here.
Great! Sounds like with this, and local switches, OPAM v2 is going to go a long way to improving the quality and utiility of the OCaml engineering ecosystem. Looking forward to it!