* Re: [Caml-list] make -> dune: recommended structure
2019-01-13 14:07 ` Nicolás Ojeda Bär
@ 2019-01-13 14:22 ` Robert Muller
2020-01-12 22:24 ` Robert Muller
1 sibling, 0 replies; 5+ messages in thread
From: Robert Muller @ 2019-01-13 14:22 UTC (permalink / raw)
To: Nicolás Ojeda Bär; +Cc: Ocaml Mailing List
[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]
This is fantastic, thank you. I could be wrong but I think my setup is
common enough that it would probably be helpful to have some variation of
your answer as an example in the dune documentation and possibly in the
quick-start guide. I suppose I could submit a PR to
https://github.com/ocaml/dune/tree/master/example.
Thanks again,
Bob
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
>>
>
[-- Attachment #2: Type: text/html, Size: 3948 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Caml-list] make -> dune: recommended structure
2019-01-13 14:07 ` Nicolás Ojeda Bär
2019-01-13 14:22 ` Robert Muller
@ 2020-01-12 22:24 ` Robert Muller
2020-01-13 0:20 ` Yawar Amin
1 sibling, 1 reply; 5+ messages in thread
From: Robert Muller @ 2020-01-12 22:24 UTC (permalink / raw)
To: Nicolás Ojeda Bär; +Cc: Ocaml Mailing List
[-- Attachment #1: Type: text/plain, Size: 4270 bytes --]
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
>>
>
[-- Attachment #2: Type: text/html, Size: 6117 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread