Am 24.10.2013 11:17, schrieb Jacob Carlborg:> I'm thinking about migrating my libraries/tools to dub. I have a couple

of questions.

  • Can I limit a package to a specific set of platforms?

Yes, it requires manually specifying the configurations:

{
    ...
    "configurations": [
        {
            "name": "library",
            "platforms": ["linux", "osx-x86_64"]
        }
    ]
}

All platforms with no matching configurations will abort with an error then. This should probably also be displayed for each package on the package registry in the future...

  • The structure of DWT currently looks like this:

  • dwt

| base (git submodule, linux and windows)
|
org.eclipse.swt.gtk.linux.x86 (git submodule, linux)
| org.eclipse.swt.win32.win32.x86 (git submodule, windows)
|
org.eclipse.swt.snippets (submodule, optional)

Ideally I would like a package, "dwt", that automatically picks the
correct submodule/package for the given platform. Is that possible?

Yes, you can specify additional configuration specific dependencies inside of each configuration:

{
    ...
    "configurations": [
        {
            "name": "gtk",
            "platforms": ["linux"]
            "dependencies": {
                "swt-gtk": {"version": ">=1.0.0"}
            }
        }
    ]
}

The only problem is that sub modules (AFAIK) are not included when the main package is downloaded from GitHub. I see three options how to solve this:

  • Somehow manually prepare a zip file on the registry with all sub modules included (with unknown server resource usage consequences)
  • Support GIT or HTTP URLs for dependencies and use those instead of (or in addition to) sub modules
  • Do include the dependencies in the registry, but mark them as not ready for general use (e.g. in the description)
  • How do I best deal with external dependencies? Libraries that should

be installed using the system package manager.

For now that's probably best left to the README or similar. The recent talk about this topic hasn't brought any news and the impression still is that handling this automatically will be a difficult/elaborate task. Of course it is possible to use a custom script based solution and run that script for example as a "preGenerateCommands" entry.

  • How are libraries compiled by default? It just compiles everything in

the source directory?

Yes, by default, if there is a "source" or "src" directory, all .d files contained in it will be compiled in. "excludedSourceFiles" Can be used to throw-out single files, or "sourcePaths" can be specified manually to only include certain sub-directories.

  • How do I best deal with packages I don't feel yet are ready to be

added to the registry but other packages depend on? Currently I use git
submodules to handle this.

See above. I think the sub-module approach should just work, but the question is how to best go about it considering the lack of GitHub support. The obvious alternative is to implement dependencies with a source URL #50. But the exact semantics need to be determined. In particular, I think that such a URL should only be a fallback when the dependency isn't found locally or on the registry, so that it's for example still possible to manually check out using GIT and use the checked out version.