RejectedSoftware Forums

On Wed, 15 Jan 2014 14:09:58 GMT, Sönke Ludwig wrote:

There is a third, and hopefully last, beta version for DUB 0.9.21. It contains four major new features:

• New per-package build system (builds individual packages as static libraries), use --combined to build everything at once (almost) like before

• New "dub test" command to run the (unit) tests of a project

• Supports (and recommends) public sub packages in sub folders. For example, the following entry in vibe.d's package description file would make the http server example available as a dependency "vibe-d:http-server-example":

  {
    ...
    "subPackages": {
      "examples/http_server"
    }
  }
  
  

• The preferred package description file name is now "dub.json" instead of "package.json" (the old name will continue to be supported).

Everything basically works, but a lot of testing is still needed to get a solid release. Please download from http://code.dlang.org/download (or GIT clone from https://github.com/rejectedsoftware/dub.git) and test with your projects, so that any regressions can be worked out early.

Not sure if this is a bug or a problem with a non-properly configured package.json, but the gfm package from code.dlang.org fails to compile: if you create a simple test project:
{

"name": "test",
"description": "A minimal D application.",
"copyright": "Copyright",
"authors": ["me"],
"dependencies": {
    "gfm" : "~master"
}

}
This fails to compile: after building the single subpackages, it appears that a non-valid dmd command is issued:
dub build --verbose
[snip]
Building gfm configuration "library", build type debug.
Ignoring all import libraries for static library build.
Trying to use pkg-config to resolve library flags for [].
pkg-config failed: pkg-config exited with error code 1
Falling back to direct -lxyz flags.
Running dmd...
dmd -lib -of../../.dub/packages/gfm-master/.dub/build/library-debug-x8664-dmd-0F143CEA0D94A974CB517ABFF7D4DCBC/libgfm.a -debug -g -w -version=Havegfm -version=Havegfmmath -version=Havegfmnet -version=Havegfmcore -version=Havegfmassimp -version=Havederelictassimp3 -version=Havederelictutil -version=Havegfmfreeimage -version=Havederelictfi -version=Havegfmimage -version=Havegfmopengl -version=Havederelictgl3 -version=Havegfmsdl2 -version=Havederelictsdl2 -version=Have_temptest -I../../.dub/packages/gfm-master/math -I../../.dub/packages/gfm-master/net -I../../.dub/packages/gfm-master/core -I../../.dub/packages/gfm-master/assimp -I../../.dub/packages/derelict-assimp3-master/source -I../../.dub/packages/derelict-util-1.0.0/source -I../../.dub/packages/gfm-master/freeimage -I../../.dub/packages/derelict-fi-master/source -I../../.dub/packages/gfm-master/image -I../../.dub/packages/gfm-master/opengl -I../../.dub/packages/derelict-gl3-master/source -I../../.dub/packages/gfm-master/sdl2 -I../../.dub/packages/derelict-sdl2-master/source
DMD64 D Compiler v2.064
Copyright (c) 1999-2013 by Digital Mars written by Walter Bright
Documentation: http://dlang.org/
Usage:
<blablabla>

Again, my guess it's a package.json problem, but I couldn't find what's wrong, so I'm submitting this. Check it out if you have any spare time!

On Mon, 20 Jan 2014 09:38:54 GMT, Sönke Ludwig wrote:

It seems like the gfm root package should specify "targetType": "none" instead of just removing all source/import paths. But since this has obviously worked before, I'll add a check/workaround for this and output a warning to use "targetType" instead.

Ok, it's a bad pagkage.json then.
When compiling with dub 0.9.20, you actually get a warning already. I guess you just need to get something a bit more informative as output.

On Mon, 20 Jan 2014 11:21:59 GMT, Sönke Ludwig wrote:

New warning message and build fix is in 7c23cbe.

That was quick! Thank you very much =)

Am 20.01.2014 13:41, schrieb ponce:

On Mon, 20 Jan 2014 09:38:54 GMT, Sönke Ludwig wrote:

It seems like the gfm root package should specify "targetType": "none" instead of just removing all source/import paths. But since this has obviously worked before, I'll add a check/workaround for this and output a warning to use "targetType" instead.

Sorry for not having done that, there is a problem indeed with targetType. It's just that I didn't know which JSON properties get inherited or not.

No problem at all, there are a lot of corners that need to be documented
better and after all this used to work until now. Also, I need to think
about this some more, because some valid use cases don't work anymore
with the new and fixed compilation model. But at least there should be
alternatives to achieve the same results (the original derelict package
using sub modules is also affected in a similar way).