On Thu, 20 Feb 2014 12:16:43 GMT, Sönke Ludwig wrote:

On Thu, 20 Feb 2014 11:41:54 GMT, simendsjo wrote:

On Thu, 20 Feb 2014 11:23:50 GMT, simendsjo wrote:

What does the error in the subject mean?

Some more info.. I'm attempting to use subpackages for the first time for a tutorial I'm making.
The error message is 

Checking dependencies in '/home/simendsjo/code/d/dtutorials/test'
Run 'dub help' for usage information.
Checking dependencies in '/home/simendsjo/code/d/dtutorials/test'
Run 'dub help' for usage information.
Checking dependencies in '/home/simendsjo/code/d/dtutorials/test'
The same package is referenced in different paths:
  number-guess ~master: /home/simendsjo/code/d/dtutorials/test
  number-guess ~master: /home/simendsjo/code/d/dtutorials/test
Error: Conflicting package multi-references.

Run 'dub help' for usage information.

And the package.json: 

{
    "name"        : "number-guess",
    "description" : "A simple number guessing game",
    "copyright"   : "Copyright © 2014, simendsjo",
    "authors"     : ["simendsjo"],

    "targetType" : "none",

    "dependencies": {
        "number-guess:cli" : "~master",
        "number-guess:web" : "~master"
    },

    "subPackages": [
        {
            "name"        : "cli",
            "targetType"  : "executable",
            "targetName"  : "number-guess",
            "sourcePaths" : ["source/cli"],
        },

        {
            "name"        : "web",
            "targetType"  : "executable",
            "targetName"  : "number-guess-web",
            "sourcePaths" : ["source/web"],
        }
    ]
}

I think this particular bug is fixed in the preview versions of 0.9.21 (the error message simply doesn't make sense). But there is a very unfortunate bug/shortcoming right now that still makes this hard to use in conjunction with branches, see #151 for a similar case. This will be fixed in the next release (0.9.22, hopefully a quick one) together with some other shortcomings of the current versioning approach (see this thread). I think it would be best to skip this topic until then (if everything goes well, in about two weeks).

Independent of this issue, I'd personally advise against promoting this particular type of sub modules, because they are quite error prone: Since all source files are located in the same import root, it's easy to accidentally use a sub package that hasn't been explicitly specified as a dependency.

This can result both, in unintended cross references between sub modules, which may be discovered only much later when someone tries to use one of the sub modules in isolation, and it can cause linker errors for users that get the dependencies wrong and it may be hard for them to find the cause.

For that reason, we've added the possibility in 0.9.21 to specify a path to a stand alone package instead:

./dub.json (or legacy "package.json"): 

{
  ...
  "subPackages": ["cli/", "web/"]
}

sub modules are then independently stored at ./cli/dub.json and ./web/dub.json and have their own separate source folders.

Sorry for the little mess that this transition currently generates, but I think this will be a very important change to get a clean package ecosystem in the long run.

Haven't read all your links, but I think I've found a bug in the current git head. 

Package 06-number-guess-defensive contains no source files. Please add {"targetType": "none"} to it's package description to avoid building it.

Then adding targetType none: 

Error executing command build: Main package must have a binary target type, not none. Cannot build.