On Mon, 21 Oct 2013 12:05:25 GMT, Joseph Rushton Wakeling wrote:
On Mon, 21 Oct 2013 11:42:55 GMT, Sönke Ludwig wrote:
Building then works simply using "cd tests/graphtest && dub build" (or "dub build --root=tests/graphtest").
Ahh, I see. I think then it might be helpful to have an opportunity to reference these as subpackages -- something akin to:
"subPackages": [ { "root": "tests/graphtest" // automatically works out everything else from the local package.json } ]... or is something like that already possible?
Something like
"subPackages": [
{
"name": graphtest,
"dependencies": {"graphtest": {"version": "~master", path="tests/graphtest"},
"targetType": "none"}
}
]
should work once that ticket is resolved. But frankly, I don't like the sub package feature that much, even if (or, rather, because) it is generally quite popular. While there are cases where sub packages are important to have (mostly so support existing source trees), they also facilitate certain not-so-clean approaches to organize a project (taking into account their public nature and the D module system). I think not only for this reason, there needs to be a basic "style guide" that gives an overview of when and why it makes sense to use each feature (build types, configurations, sub packages, distinct packages).
Other ideas can probably make distinct packages more attractive:
- Display all those distinct sub folder packages in the registry, just like sub packages
- Allow them to be referenced using the same syntax ("mainpackage:nameofpackageinsubfolder")
- Support single file packages
If all these points are supported, I think that it will be safe to declare "subPackages" as a mildly discouraged compatibility feature without hampering any other use cases.
In any case, I think for now I'm happy with the subPackages solution I came to. Thank you ever so much for all your help here -- it's really been a joy having such fast and helpful feedback and bugfixes!
You're welcome! I'm always glad when things can be quickly fixed.