Checking version dependencies using jbuilder

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.

2 Likes

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?

2 Likes

That sounds like a really good idea, and fits in well with the new local features in opam2. A feature request in https://github.com/ocaml/opam/issues would be appreciated.

No need to open an issue. This is already in v2, see here.

2 Likes

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!

1 Like