default alias usability issues for projects with nested folders

[Khady]

One convenient characteristic of dune is that all file targets automatically belong to the @all alias, and default will run all. It means that developers can add an executable basically where they want and rely on dune build to do the right thing. But in a big repository we don't always want to build everything that has been declared.

Imagine a repository that looks like this, with multiple level of nested folders, and those folders can contain one or multiple exe/lib:

├── dune-project
├── teamA
│   ├── dune
│   └── project1
└── teamB
    ├── project1
    │   ├── dune
    │   ├── exe1.ml
    │   ├── exe2.ml
    │   ├── exe3.ml
    │   ├── lib1
    │   │   ├── dune
    │   │   └── lib1.ml
    │   └── utils
    │       ├── dune
    │       └── exe4.ml
    └── project2

I've populated only teamB/project1, but we can assume that all the other folders also contain code relying on dune.

We have some binaries that are either still in development or for one off projects. We don't expect that they should be built by dune build. For example exe3.exe in my repository.

My first issue is that I can express that default should be all without exe3.exe. As soon as I start using default in a dune file I have to list all the alias/targets that I want to build in that folder. It quickly becomes verbose. Especially if one is using multiple modes per executable or if they are many nested folders.

(rule
 (alias default)
 (deps
  exe1.exe
  exe2.exe
  (alias_rec utils/default))
 (action (progn)))

Note that I have to create an empty action, it isn't very elegant.

Nevertheless, if run dune build @@teamB/project1/default it builds what I want:

_build
├── default
│   └── teamB
│       └── project1
│           ├── exe1.exe
│           ├── exe1.ml
│           ├── exe1.mli
│           ├── exe2.exe
│           ├── exe2.ml
│           ├── exe2.mli
│           ├── lib1
│           │   ├── lib1.a
│           │   ├── lib1.cmxa
│           │   └── lib1.ml
│           └── utils
│               ├── exe4.exe
│               ├── exe4.ml
│               └── exe4.mli
└── log

My second issue is that a build from a parent directory of teamB/project1 won't use my default alias! As soon as I have one folder in my repository which relies on a custom default to do the right thing I have to create a default alias in all the parent dune files. Which introduces the first issue previously mentions.

example$ dune build @@teamB/default
example$ tree _build
_build
├── default
│   └── teamB
│       └── project1
│           ├── exe1.exe
│           ├── exe1.ml
│           ├── exe1.mli
│           ├── exe2.exe
│           ├── exe2.ml
│           ├── exe2.mli
│           ├── exe3.exe
│           ├── exe3.ml
│           ├── exe3.mli
│           ├── lib1
│           │   ├── lib1.a
│           │   ├── lib1.cma
│           │   ├── lib1.cmxa
│           │   ├── lib1.cmxs
│           │   └── lib1.ml
│           └── utils
│               ├── exe4.exe
│               ├── exe4.ml
│               └── exe4.mli
└── log

5 directories, 18 files

You can see that exe3.exe was built. It's because in teamB the default alias will actually run @all, which means that in teamB/project1 dune will build all instead of default.

[nojb]

Note that I have to create an empty action, it isn't very elegant.

It is a bit orthogonal, but note that you can use an (alias) stanza to avoid defining an empty action:

(alias
 (name default)
 (deps ...))

[Khady]

Oh thanks! I remembered seeing a warning when using the alias stanze and wrongly thought that it was deprecated, especially as there's no alias snippet in the vscode extension. But actually it's only the usage of action in an alias which is forbidden. Adding the alias snippet in ocamllabs/vscode-ocaml-platform#1347 to apologize :)