One year later, take-two on transitioning from make to dune for an
OCaml-based PL course. We have a course library, say, code.cma, stored in a
folder outside the dune workspace, say /Users/studentX/lib/, several course
projects use the definitions in this course library.
As I understand it, the singular "library" in a dune stanza refers to the
artifact created by a build (the output) while the plural "libraries"
refers to -inputs- to the current build. How to inform dune about the path
to look for non-local .cma files? (As in the include switch > ocamlc -I
path ...)? I found the following in the dune documentation:

Finding external libraries
> When a library is not available in the workspace, dune will look it up in
> the installed world, and expect it to be already compiled.
>
> It looks up external libraries using a specific list of search paths. A
> list of search paths is specific to a given build context and is determined
> as follow:
>
> if the ocamlfind is present in the PATH of the context, use each line in
> the output of ocamlfind printconf path as a search path
> otherwise, if opam is present in the PATH, use the output of opam config
> var lib
> otherwise, take the directory where ocamlc was found, and append ../lib to
> it. For instance if ocamlc is found in /usr/bin, use /usr/lib
>

I didn't know what "A list of search paths is specific to a given build
context..." meant but ocamlfind -is- present in the PATH and the command

> ocamlfind printconf path


shows

/Users/muller/.opam/default/lib

seems reasonable (though I suppose I should go sort out exactly the
difference between a package and a library). Anyway, I couldn't find a more
civilized way to extend ocamlfind's search path so I edited
/Users/muller/.opam/default/lib/findlib.conf
by hand to include the path to our course library. Dune still cannot find
our course library.

I could be wrong, but it seems this setup (with a standard site library
code.cma) is pretty common, so I'm sure I'm missing something super-obvious
in the documentation. Any leads would be appreciated.

Bob Muller



On Sun, Jan 13, 2019 at 9:07 AM Nicolás Ojeda Bär <
nicolas.ojeda.bar@lexifi.com> wrote:

> Dear Bob,
>
> Your present directory structure is just fine. A single `dune` file at
> `src/dune` with the contents
>
>     (executable
>      (name compile)
>      (public_name translate))
>
> should be enough. Here I am assuming that all modules in `src/` are part
> of the compiler. If this is not the case you need to specify the modules
> you want to include as follows:
>
>     (executable
>      (name compile)
>      (public_name translate)
>      (modules compile ast symbol ...))
>
> Note: if you have a file `parser.mly` in your project that needs to be
> processed with `ocamlyacc` then you need to declare this in its own stanza:
>
>     (ocamlyacc parser)
>
> Similarly an `ocamllex` file `lexer.mll` needs to be declared with
>
>     (ocamllex lexer)
>
> Finally, you need to make sure there is a `<foo>.opam` file at the root of
> your project. This file can be be empty if you do not actually use `opam`
> but the name `foo` is used by `dune` to identify the "package" your
> executable belongs to. Once these files are in place, you can build your
> project with
>
>     dune build
>
> Best wishes,
> Nicolás
>
> On Sun, 13 Jan 2019 at 14:31, Robert Muller <robert.muller2@gmail.com>
> wrote:
>
>> Greetings. I have a toy compiler made up of ~20 modules:
>>
>> ast.mli ast.ml symbol.mli symbol.ml ...
>>
>> and a top-level in compile.ml. These sources are compiled and linked
>> using a Makefile which invokes ocamlc. I'll call the resulting compiler
>> "translate".
>>
>> At present I have *all* of these files resident in a single src/
>> directory. I'm considering converting the build to dune for the semester.
>> What would the recommended directory structure be and what would the dune
>> file(s?) and stanzas look like? I assume this is in the middle of dune's
>> wheelhouse but I wasn't able to find anything on it in the examples or
>> documents. I assume/hope I don't have to put the modules in a library.
>> Thank you,
>> Bob Muller
>>
>