Plan for Dune 3.0

Just to confirm, Dune will still be able to read and generate META files, correct? Internally we have packages built by both Dune and other build systems. We rely on META files for interop between them.

1 Like

do you guys have plans for a generic release-mode?
I’m mostly interested in optimized & stripped executables when I invoke dune install without having to write custom rules.

1 Like

What is your workspace layout? Only workspaces using nested vendoring will be affected.

We do sometimes nest (e.g. ocaml-ci vendored ocluster, which vendored obuilder):

The latest master is only one-level deep, though.

I believe dune-release is more specific to a github-based workflow?

Yes, dune will still read and generate META files.

1 Like

Yes, we’re aware of the overloaded terminology and I agree that it’s a good idea to distinguish between package management and vendoring. We discuss it in a little more detail here: Vendored_dirs and release mode · Issue #3911 · ocaml/dune · GitHub


Thank you @jeremiedimino for the detailed answer. As @hongchangwu mentioned, we’re using dpkg for packaging.

Since @rgrinberg clarified that:

Yes, dune will still read and generate META files.

We think we should be fine with removing the dependency on the ocamlfind executable being available, because we do set an OCAMLPATH where the relevant META files exist.

1 Like

By “stripped”, do you mean executables compiled without -g? I’m afraid we don’t have any plans to add something specific here, but we do let users customize flags. Is that not enough?

Well, the compiler doesn’t have a flag corresponding to gcc’s -s. So my usual workflow involves specifying ocamlopt flags without -g and like so: -ffunction-sections -compact -ccopt -Os -ccopt -s -ccopt -flto -ccopt -Wl,--gc-sections (ocaml >= 4.10) followed by a custom rule that runs strip -s on the resulting executable just to be extra sure.

The shrink in size vs a default dune install is around 30~50% and reaches ~75% for smaller executables.


For the warnings, a first task is just to look at how people customize warnings, and if the documentation is clear on those points. We could have specific ways to specify those compiler flags. Perhaps using the new named warnings from the compiler.

The second is indeed as you propose to see if we can show the warnings at different times. Warnings specific to the editor is a good idea. Another possibility is for some warnings such as unused value to delay them to runtest or a runcheck, which would print the warnings delayed (e.g logged separately) and fail if it is not empty. But one design question is what is the set of compiled file considered.

The third is to clarify what we do for new compilers with new warnings.

I was just thinking about a release mode since it’s a common thing among build tools. Many distros packaging software (and I can imagine they’re not the only use case) opt for turning on extra optimizations, minimizing executable size, and stripping executables in favour of separate debug symbols.


(Since dunes plan to remove automatic creating dune-project in 3.0)

How is your current solution to prevent running dune in a directory?

It occurs when I have code/pj1 code/pj2 but carelessly run dune at code where code is just a folder to put my projects.


Nope, but seems worth discussing this point. i.e. should dune do something if it finds no dune-project or dune-workspace file? I’m adding this to the agenda of the next Dune meeting.

I just chat it with a lab member and he also has also this concern.

Another concern is I cannot use ^C or ^D to cancel when dune starts scanning after I realize it’s at a wrong path.

$ code> dune build                                                                                       15:26:46
Info: Creating file dune-project with this contents:
| (lang dune 2.8)
Scanned 600 directories ...

I also had tried directory-based way e.g. direnv or alias dune with a script to check the path though none of them looks very good to me…

1 Like

Indeed. We should insert checkpoint to check for signals during the initial scan. Could you open a ticket about that so that we remember to do it? In any case, if you press ^C several times quickly, Dune will abort. It’s not a clean exit, but at least it does the job. Dune prints a message when it exits this way.

Here is the ticket on the dune project.

I just learn here (and tried) that hitting ^C several times can perform an emergency exit. I still need to delete the dune-project and _build in the path which is not intended to run dune build, so I also mention this in the ticket. I don’t know what are the convention or usual behaviors of a program performing ^C signal handling besides exiting soon.


relying on the findlib configuration file I’m relying on findlib.conf to cross compile packages on esy, currently esy just sets the OCAMLPATH but we intended to move esy to findlib.conf, as it seems like a better way to setup the environment and it reduces the size of the environment.

I believe @anmonteiro is also using the same for cross compiling on nix.

@EduardoRFS ack. Actually, Dune does the same for cross-compilation. More precisely, when compiling with -x <target>, or when setting up cross compilation via the dune-workspace file, it reads the corresponding findlib.conf file installed by the OCaml cross-toolchains and cross-packages · GitHub opam repositories.

So it wouldn’t be too difficult to change Dune so that it always read the findlib configuration file. However, there is on-going work to add support for OCAMLPATH in the compiler and eventually deprecate ocamlfind. So moving from using OCAMLPATH to using findlib.conf feels like going backward.

@EduardoRFS see in particular this comment. Defining standard OCaml development lifecycle processes - #15 by dbuenzli

10 posts were split to a new topic: OCaml RFC#17: library linking proposal