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.
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.
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):
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.
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
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.
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/pj2 but carelessly run dune at
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-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…
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
_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