Internal error when 2 dune-project files have the same name stanza

[clecat]

When launching dune in a directory containing several dune-project files (on itself and the subdirectories) with the same value for the stanza name triggers an internal error message:

Internal error, please report upstream including the contents of _build/log.
Description:
("Scope.DB.create got two projects with the same name"
 (project1 (test src2))
 (project2 (test src1)))
Backtrace:
Raised at file "src/stdune/exn.ml", line 40, characters 5-10
Called from file "src/scope.ml", line 119, characters 8-170
Called from file "src/scope.ml", line 143, characters 6-79
Called from file "src/super_context.ml", line 301, characters 4-123
Called from file "src/gen_rules.ml", line 327, characters 6-161
Called from file "src/fiber/fiber.ml", line 99, characters 6-13
                   
I must not segfault.  Uncertainty is the mind-killer.  Exceptions are
the little-death that brings total obliteration.  I will fully express
my cases.  Execution will pass over me and through me.  And when it
has gone past, I will unwind the stack along its path.  Where the
cases are handled there will be nothing.  Only I will remain.

The directory architecture was the following:

├── src1
│   └── dune-project
└── src2
    └── dune-project

With both dune-project files content being:

(lang dune 1.9)
(name test)

_build/log content:

# dune build
# OCAMLPARAM: unset
$ /usr/bin/nproc > /tmp/dune03af81.output 2> /dev/null
$ /home/charles-edouardlecat/.opam/ocaml-base-compiler/bin/ocamlc.opt -config > /tmp/duned6ad4a.output

[rgrinberg]

@diml @avsm

Was our original intention for dune project names to be unique? This seems like a fragile assumption. We should make it possible to work with duplicate project names in dune.

[clecat]

Yes, I was not asking for dune to support several projects with the same name, the idea was just having a cleaner and maybe more directly explicit error message than an internal error

[rgrinberg]

Well, it's really not that hard to add such support. In fact, I wouldn't be surprised if we had it before and we accidentally broke it. I think we should restore it as it isn't so hard to support and it lifts another burden from users like @avsm who build massive workspaces at once.

[avsm]

It would make vendoring much easier to be robust to duplicate dune-project file names.

…

On 28 Jun 2019, at 14:13, Rudi Grinberg ***@***.***> wrote: Well, it's really not that hard to add such support. In fact, I wouldn't be surprised if we had it before and we accidentally broke it. I think we should restore it as it isn't so hard to support and it lifts another burden from users like @avsm who build massive workspaces at once. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ghost]

Yh that seems fine, however we need to check carefully the various places where we compare project names. Maybe we should systematically include the path in the OCaml value that represent the project name.

[rgrinberg]

This will no longer be a limitation starting from 1.11 :)