gsl fails to install since recently about opam-repository HOT 9 CLOSED

the issue here is that do_common will read gsl_include.sexp at init time (IO happens outside of a function), so running do_sf.exe will read that file. The correct fix is to add gsl_include.sexp as a dependency to force an ordering in the dependency graph. otherwise, this will depend on the order in which the modules of the library are built: if Sf is built before Cdf or Const, it will fail. It's true that -j 1 will prevent rules from firing in parallel but dune can not guarantee anything about the order in which the modules are built. This has probably changed several times between dune versions.

from opam-repository.

Mmh, I can't reproduce it locally and it was supposed to be fixed by #19244
Is this deterministically reproducible with your setup?

from opam-repository.

It is strange. It seems deterministically reproducible when I (try to) install all these packages (except ppx_globalize) at once in an empty 4.13.1 switch. However, installing orpie alone in an empty switch, or installing it after all the others are installed, succeds.

from opam-repository.

I've tried to reproduce locally with all those packages at once but it worked for me

from opam-repository.

I just remembered that I applied a patch in Debian. A similar fix was applied upstream, but not released yet. A kind of race condition does exist in the package in its current form. Maybe the patch should be applied in the opam package as well?

from opam-repository.

I was under the impression that dune build -j1 (from #19244) would be an alternative fix for this. Does -j not make the build order deterministic in dune? cc dune devs @rgrinberg @emillon @Leonidas-from-XIV @gridbugs

from opam-repository.

This has probably changed several times between dune versions.

ah, I see. Very unfortunate. Thanks a lot!

@glondu could you open a PR to add your patch to the relevant versions? (and maybe restore "-j" jobs at the same time)
@mmottl could you do a release when you have some spare time?

from opam-repository.

I mean, on the other side I can't tell you for sure it has changed, but the build engine has changed enough that I'd say this kind of thing is likely to have changed.

from opam-repository.

With the introduction of background threads, not even -j 1 guarantees a deterministic order of actions. There's some environment variables to disable the various background threads if this desirable.

from opam-repository.