Expected Behavior

Nested INSIDE_DUNE being SHOULD NOT cause Dune to use single core for building. The specific case I encountered was dune pkg builds the OxCaml in a single thread due to this.

Actual Behavior

I ran into dune pkg taking unusually long to build the OxCaml compiler (5.2.0+ox). For context, it took over 30 minutes to build on my machine:

/usr/bin/time dune build
2505.62user 257.63system 32:00.89elapsed 143%CPU (0avgtext+0avgdata 1222984maxresident)k
4851624inputs+19836216outputs (2828major+79527647minor)pagefaults 0swaps

Discussing with @art-w, he pointed out that this is a case of nesting INSIDE_DUNE causing Dune to not use concurrency when building the compiler. This happens because the OxCaml compiler uses Dune to build the compiler itself (unlike mainline OCaml). This is a specific case, but I do wonder if this is possible elsewhere.

The environment variable is getting set globally at

The solution for this particular case could be to manually unset INSIDE_DUNE in the build of the oxcaml compiler. But this could affect the build with opam. I'd be interested to know if this is a desirable solution or if there are other ways to potentially fix this. As such this is a UX issue of build taking unusually long, not a correctness issue.

Reproduction

1. Clone the hello-oxcaml repo: https://github.com/Sudha247/hello-oxcaml/tree/update
2. Build with dune package dune pkg lock && dune build

Specifications

• Version of dune (output of dune --version): 3.20.2
• Version of ocaml (output of ocamlc --version): 5.2.0+ox
• Operating system (distribution and version): Ubuntu 20.04

Keywords

threads, jobs