sourcePaths does not work as documented with configurations

[Geod24]

System information

• dub version: DUB version 1.20.0, built on Mar 9 2020
• OS Platform and distribution: Mac OSX 10.15.4
• compiler version: DMD 2.091.0

% dub init dub-bug -n
Successfully created an empty project in '/Users/geod24/projects/dub-bug'.
Package successfully created in dub-bug
% cd dub-bug
% mkdir source/app1/ source/app2
% echo "void main () {}" > source/app1/main.d
% echo "void main () {}" > source/app2/main.d
% rm source/app.d

dub.json edited to:

{
    "name": "dub-bug",
    "configurations": [
        {
            "name": "app1",
            "targetName": "bug-app1",
            "sourcePaths": [ "source/app1" ]
        },
        {
            "name": "app2",
            "targetName": "bug-app2",
            "sourcePaths": [ "source/app2" ]
        }
    ]
}

Result:

% dub build -c app1
Performing "debug" build using dmd for x86_64.
dub-bug ~master: building configuration "app1"...
Error: module main from file source/app2/main.d conflicts with another module main from file source/app1/main.d
dmd failed with exit code 1.
% dub build -c app2
Performing "debug" build using dmd for x86_64.
dub-bug ~master: building configuration "app2"...
Error: module main from file source/app2/main.d conflicts with another module main from file source/app1/main.d
dmd failed with exit code 1.

However, according to the documentation:

Allows to customize the path where to look for source files (any folder "source" or "src" is automatically used as a source path if no sourcePaths setting is specified)

Emphasis mine. This only works if sourcePaths is at the top level:

{
    "name": "dub-bug",
    "targetName": "bug-app1",
    "sourcePaths": [ "source/app1" ]
}

Compiles successfully.

[s-ludwig]

That sentence really is fuzzy. So the current behavior is "... no sourcePaths setting is specified outside of a configuration block". It would probably make more sense to change the semantics to "... setting is explicitly specified for a particular configuration, either within the configuration block or outside of it".

[Geod24]

It would probably make more sense to change the semantics to [...]

That's the behavior I was expecting.

For reference, my use case is a main executable, and a few small tools next to it.
The main executable is the first entry in the configurations array, then the second is unittest, then the 2-3 tools. Each tool live in source/$MAINPKG/tools/$TOOLNAME/.
Each tool need to import from $MAINPKG (package protection), hence why they live within it.

I could use subpackages for that but I'm really note fan of Vibe.d's $ROOT/http/vibe/http/, and prefer to have all my files grouped in the same "root" source directory (make some tasks, e.g. grep, a bit simpler). We also have source/$CPPLIBNAME/ and source/$CPPLINAMEd/ (the former contains the C++ code and some build script, and the later contains the bindings for said C++ code).

[andre2007]

Coding which causes current behavior be found here

dub/source/dub/package_.d

Line 674 in a12c19f

immutable hasSP = ("" in bs.sourcePaths) !is null;

[atilaneves]

There's a workaround which I just tried that seemed to work: don't name the top-level directory source.