Two-parter. I’m converting a large-ish codebase from omake to dune.
PART ONE
Is it possible to tell dune, from the toplevel of a big tree with many sub-dirs that contain dune files with executable stanzas, to only build all .exe files for the whole tree?
Doing dune build @all builds all .exe files, but also .bc files. I’m using promote and .bc files are being generated and promoted to the source tree as well as .exe files.
Aside from being messy, it significantly increases the build time to have dune also generate runnable .bc files that aren’t going to be used.
I can throw (modes (native exe)) in each executable to restrict what gets built to only .exe, but it feels like I’m on the wrong track with this.
PART TWO
My OMakefiles had very make-like targets, such as install: and install-remote: which runs an external script, or shells out to the UNIX install and rsync commands with args (after building the .exe files). Is there a way to do something similar? I don’t want to turn things into opam packages, or stick things in the opam root, which it seems dune is geared for. It seems clunky to try to get dune to do a simple make-like thing.
I just want to say cd $REPO/tools; dune install and have it build all .exe files in the directory and install them to /usr/local/bin/ without struggling.
It’s so clunky (or I’m so confused) that … right now I’m working around this by… also sticking a Makefile in my project directories that will call the right dune builds before dispatching to install or rsync or whatever. Feels a bit like one step backwards. Is this the intent?
For part one, since the version 2.0 of the dune language the default is to build only the .exe, which is a native executable or a bytecode one if ocamlopt is not available. So as long as you have (lang dune 2.0) in your dune-project file dune build @all will build only the .exe files.
For part two, you do need to declare a package name if you want to install things on the system via dune install. The idea is that you declare one or more packages and then attach various items to them. However, you no longer need to declare an opam package, and more precisely you no longer need a <package>.opam file to declare a package to Dune. Instead, you can use a (package ...) stanza in your dune-project file. All you need is a line (package (name foo)) in your dune-project file. You can then ask Dune to generate the opam files via (generate_opam_files true) if you want.
Right now you can’t ask dune to build and install at the same time. I remember that this was discussed in the past and one issue is that we often want to build and install with different permissions. For instance, you need to be root to install in /usr/local/bin but you don’t want to build as root. Though this could be added as an option.
Regarding remote install, that’s not supported at the moment. Thought we could add support for customising the install command, don’t hesitate to open a ticket on the tracker about this, or even better submit a PR Note also that dune build @install generates <package>.install files that are relatively simple to read, so parsing these files could be an option as well.
It’s so clunky (or I’m so confused) that … right now I’m working around this by… also sticking a Makefile in my project directories that will call the right dune builds before dispatching to install or rsync or whatever. Feels a bit like one step backwards. Is this the intent?
Calling dune from a toplevel Makefile seems fine to me. A lot more developers know about make than dune, so having a Makefile is a good entry point. But if you have to write several ones with specific contents, that’s not great indeed. Generally what I do is stick a toplevel makefile that I use for calling various dune commands or other top-level operations while I work the project, but then make sure that make is not required for release builds, to maximise portability and allow the project to be part of a bigger workspace. And as dune evolves, such Makefile tend to thin out and eventually become superfluous.
Throwing 2.0 into our dune-projectdid indeed neatly solve the problem. Thanks @jeremiedimino!
As suggested, opened an issue here to talk about this feature further:
As for this part:
Sensible, although you could imagine the (hypothetical!) external install program/command-line that you’ve specified to install files can escalate its privileges as needed, such as with sudo. Then you could build and install in one go.
Note also that 