Am 24.10.2013 15:04, schrieb Jacob Carlborg:> 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?

It accepts the same combination of identifiers as the build setting suffixes, the example above matches Linux (any architecture, any compiler) or OS X on X86-64 (any compiler).

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

My idea in this case was to specify the git URL each dependency instead of relying on submodules. But this is of course an alternative. The only drawback is that it would tie everything more to GIT, whereas now with the .zip system it is completely VCS agnostic. Having said that, I don't find it to be particularly bad to have a standard VCS (like GIT is for Go).

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

Hm maybe a simple string like "description"? That way we have a clear cut between now and the point when we support machine readable external dependency specifications (if ever). Thinking of something like this:

"systemDependencies": "OpenSSL 0.9.x or 1.0.x, libevent 2.0.x and GTK+ 3.8"