On 2013-10-24 12:35, Sönke Ludwig wrote:

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...

Just specifying the OS would mean just for that OS but for any architecture?

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

If dub supports the git protocol, either through the git executable or
libgit2, then git submodules would work. Just run git clone <address> <br>--recursive or the equivalent using libgit2.

  • Do include the dependencies in the registry, but mark them as not ready for general use (e.g. in the description)

Ok. It sounds like the easiest would be to just include them in the
registry. I might restructure the whole DWT package anyway. There's some
duplicated code.

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.

Ok, I see. What about having a dedicated field for this? I would not
install anything, just be a list. This would allow to have an official
place to state the external dependencies.

/Jacob Carlborg