We have this configuration of submodules:
/dub.json -> include/gs/utilities/dub.json via relative path
/dub.json -> include/gs/keyvaluestore/dub.json via relative path
/include/gs/keyvaluestore/dub.json -> /include/gs/keyvaluestore/include/gs/utilities/dub.json via relative path
(it's a git submodule but only checked out one deep.)
In this situation, I think the build for /include/gs/keyvaluestore should use /include/gs/utilities of the root project, matching by name. The argument is that utilities is versioned as path in the root dub.selections.json, and dub.selections.json is supposed to be authoritative for every package that's part of the build. However instead, keyvaluestore tries to find its own relative subpath, which is not checked out, and fails to build with a missing package.
(Having multiple versions of the same package in different paths doesn't work anyhow, because the modules conflict.)
We have this configuration of submodules:
In this situation, I think the build for
/include/gs/keyvaluestoreshould use/include/gs/utilitiesof the root project, matching by name. The argument is thatutilitiesis versioned as path in the rootdub.selections.json, anddub.selections.jsonis supposed to be authoritative for every package that's part of the build. However instead,keyvaluestoretries to find its own relative subpath, which is not checked out, and fails to build with a missing package.(Having multiple versions of the same package in different paths doesn't work anyhow, because the modules conflict.)