From: Jocelyn Sérot <firstname.lastname@example.org> To: Caml Mailinglist <email@example.com> Subject: Re: [Caml-list] A (silly ?) question about opam and ocamlfind Date: Thu, 15 Aug 2019 08:26:57 +0200 Message-ID: <09561F13-3BF9-4978-9984-82962C030488@uca.fr> (raw) In-Reply-To: <firstname.lastname@example.org> Thanks for the answer and the « historical » perspective. In fact, I’ve started to use dune a few weeks ago and this is a problem with the transition from a package previously developed with ocamlfind to dune which triggers my initial question. Anyway, after carefully re-reading the opam and dune documentation, i’ve finally fixed the problem. I’m about to publish a small repository on github summerizing the solution(s) with the hope that it can be useful to other programmers. Jocelyn Le 14 août 2019 à 21:08, email@example.com a écrit : > Hello! > > The more tools are added on top of each others to make life easier for newcomers, and the harder it is to understand what's happening. > > So let's get back to the beginning. I'm assuming you know already most of this but I'd rather give a picture of the whole stack so that you know which documentation you need to read to learn the details about various steps. > > OCaml compiler without any other helper tool knows very little about where to find the files it needs. > Following the tradition, it just knows one directory, where the system libraries are located. And it takes everything else from the command line: the inputs (some .ml, .cmx, .cmxa, .o, .a, etc files, some additional paths where to look for libraries if more are needed), and the single output (-o somefile). > > You can work only with this, that's very simple, but also quickly cumbersome as the number of libraries you need grow, each requiring other libraries and special options for the compiler, recursively. > So at some point, you want a package manager: something that organise libraries in your local disk with some additional metadata about what depends on what, so that you only have to say "I want to link with the foobar, preferably the lwt variant". > This is ocamlfind. To play by the rules, you have to install all the package in a given directory, with an additional small META file that contains the dependencies and various options and other meta data such as a unique name and a description. > If library authors play by the rules and provide that META file and install their libraries in a standardized manner (which is greatly simplified by ocamlfind command line tool) then everything become as easy as `ocamlfind ocamlc -package 'foo bar baz' my_source.ml`. > > This is great and nice, and by and large OCaml library authors have played by the rules for a very long time now (such a tool, to be successful, have to be reliable and _stable_ for a long time ; ocamlfind have been very successful and essential to OCaml popularity, because it has stayed the same for many years ; thank you so much to its maintainers to resist the need to break backward compatibility). > > There is still an important annoyance though: for the above to work, you still need libraries foo, bar and baz to be downloaded, compiled, and installed on your local machine. For this, you need a standard package repository. This is OPAM. Opam also have it's small file with metainfo about each package, except this one is called "opam" (or "$package.opam") and states where to get the package from, what command to run to build it, and how to install it. > Sounds familiar? Yes that's exactly what your Linux distribution does, but it works also on non-linux systems and is also updated much quicker, as there are less bureaucracy involved (notice it solves a human problem not a technical problem here). > > There is a bit of redundancy between ocamlfind and opam, because, despite ocamlfind being used by >90% of packages, opam is ocamlfind agnostic and can work, in theory, for non-ocamlfind packages (indeed, it can also be used to deploy about anything not only OCaml packages). So you have to give names, description, dependencies both to ocamlfind and opam. > But that's only a minor annoyance. > > If it really bothers you, then you can use another tool on top of all that, such as dune, that will not only build your project but also write the META and the opam file for you (and more). With the risk that, if something fails at this point, you have all the above stack to unfold to understand what's happening. > > If you have read this far then maybe you are interested in the topic of software packaging and deployment. > Then it must be mentioned that better, more sophisticated package managers do exist, which solve this whole problem once and for all, such as nix or guix, and that hopefully one day we will all abandon our compartmentalised solutions that are popular today and move on to the next level.
next prev parent reply index Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-14 13:20 Jocelyn Sérot 2019-08-14 13:42 ` Kakadu 2019-08-14 19:09 ` rixed 2019-08-15 6:27 ` Jocelyn Sérot [this message] 2019-08-15 8:25 ` Malcolm Matalka
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=09561F13-3BF9-4978-9984-82962C030488@uca.fr \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
caml-list - the Caml user's mailing list Archives are clonable: git clone --mirror https://inbox.ocaml.org/caml-list AGPL code for this site: git clone https://public-inbox.org/ public-inbox