[opam-devel] Generating .install file

Daniel Bünzli daniel.buenzli at erratique.ch
Mon Jul 8 13:23:38 BST 2013

Le lundi, 8 juillet 2013 à 08:52, Thomas Gazagnaire a écrit :
> And it needs to be named `<package-name>.install`.
> Both of these limitation (root + package name should be known) are a bit severe,  
Well not really:  

1) opam invokes the build system from the root so you are there.
2) The environement variable $OPAM_PACKAGE_NAME has the name  

So it's not that severe.
> so I was thinking to let the user specifies which install file he wants to use in the OPAM file, in the same spirit at the 'patch' fields. As nobody never really used this file as it was intended to (eg. generated by the build system)

Well there is now such a system... Having had a build crisis over the week-end, being fed up with any build system or meta build system doing half of the things I'd like them to do and/or in a undocumented way. And realizing that oasis was actually doing very little work for me but costing too much time in terms of how I can express that in there, how wait I cannot so I need to patch the _tags file anyway etc. I decided to reclaim control and I implemented a trivial system that should work for my (simple) packages. Basically it:

1) Uses an opam description file for the metadata (but doesn't do something particular with it, I got a little bit less obssesed by DRY to simplify things).  

2) Uses ocamlbuild to build. Write yourself the support files for libs (.mllib, etc). It's not hard and reasonably documented, no need for oasis to generate them.  

3) Write the META file yourself, it's not hard and handles optdeps stuff gracefully with exists_if. No need for oasis to generate them or meta program them. Here for example for Vg which has conditional support on js_of_ocaml:


4) For building your package just list what you want to build and install in a simple script that handles conditionals. This is how this script looks for Vg:


Yes it's hand written, I don't care, at least it's very explicit. It uses the functions of this *trivial* package-independent script:


that just records what you `add` in which section (filtering out native stuff if you don't have support for it or choosing byte vs native for binaries). Then invokes a one shot `ocamlbuild` on what you added if you call `build` and generates an opam install file if you call `install` with what it recorded (see the invocation in the above `build` script).

This leads to the following simple opam package file:




More information about the opam-devel mailing list