DUB 0.9.21 is currently in the RC stage. Before tagging a release, I'd like it to get a little more exposure. Apart from checking if building works (dependencies are now built separately by default), there are two new features that could also benefit from more testing:

 - "dub test" will now automatically execute the unit tests of a
   package (see "dub test --help" for more information)

 - Sub packages can now be in sub folders (the recommended approach):

   "name": "somepack",
   "subPackages": {
       "subpack1/",
       "plugins/someplug/"
   }

   Those sub packages can be publicly referenced as a dependency for
   example as "somepack:subpack1" (assuming that the the package in
   "subpack1")

The binaries can be found on http://code.dlang.org/download ("Latest preview").

Pre-release thread on the DUB forum:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/965/

On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig wrote:
> dependencies are now built separately by default

You mean DUB won't recompile dependencies from scratch but will do it incrementally? I'm not really sure how it does it right now either.

Am 12.02.2014 11:11, schrieb Andrej Mitrovic:
> On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig wrote:
>> dependencies are now built separately by default
>
> You mean DUB won't recompile dependencies from scratch but will do it
> incrementally? I'm not really sure how it does it right now either.

In 0.9.20, it used to gather all source files of all packages in the dependency tree and built them at once (when necessary). Now, by default, it will build each dependency as a separate static library and also builds only those dependencies that have changed or those that depend on other dependencies that have changed.

The --combined switch can be used to get (almost) the old behavior. Almost, because DUB now also respects the exact "targetType" of a package and will always build a static library if "staticLibrary" is given and aways includes the source files on the parent package build command when "sourceLibrary" is used. Previously, all dependencies were basically treated as "sourceLibrary".

On Wednesday, 12 February 2014 at 10:58:28 UTC, Sönke Ludwig wrote:
> In 0.9.20, it used to gather all source files of all packages in the dependency tree and built them at once (when necessary). Now, by default, it will build each dependency as a separate static library.

Nice. Hope it works fine (especially w.r.t. that -allinst mess we've had since recently).

On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig wrote:
> DUB 0.9.21 is currently in the RC stage. Before tagging a release, I'd like it to get a little more exposure. Apart from checking if building works (dependencies are now built separately by default)

How do I handle `example` subdirectories with the new build process? I looked at vibe.d's examples (the simple HTTP server stuff to be specific) but they don't seem to handle linking (do they really build without --combined?). Is there a way to add linker search directories so my examples can link to the library's static library builds? Or is this supposed to be handled automatically for library dependencies?

>  - "dub test" will now automatically execute the unit tests of a
>    package (see "dub test --help" for more information)

I can confirm this works for the LuaD package, which is a pretty typical D library in terms of structure.

El 12/02/14 09:53, Sönke Ludwig ha escrit:
> The binaries can be found on http://code.dlang.org/download ("Latest preview").

On Debian 7.4 64-bit:

$ dub
dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dub)


No problem on Debian 7.4 32-bit.

-- 
Jordi Sayol

Am 12.02.2014 14:14, schrieb Jakob Ovrum:
> On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig wrote:
>> DUB 0.9.21 is currently in the RC stage. Before tagging a release, I'd
>> like it to get a little more exposure. Apart from checking if building
>> works (dependencies are now built separately by default)
>
> How do I handle `example` subdirectories with the new build process? I
> looked at vibe.d's examples (the simple HTTP server stuff to be
> specific) but they don't seem to handle linking (do they really build
> without --combined?). Is there a way to add linker search directories so
> my examples can link to the library's static library builds? Or is this
> supposed to be handled automatically for library dependencies?

The latter. The target binaries of dependencies (recursively) are automatically linked against the final application.

Specifying linker search paths is not possible right now (at least some time ago this was problematic for DMD on Windows, not sure what the current state is). But specific library files can be added as `"sourceFiles"`. Those will be passed to the compiler at the linking stage, which passes them on to the linker.

>>  - "dub test" will now automatically execute the unit tests of a
>>    package (see "dub test --help" for more information)
>
> I can confirm this works for the LuaD package, which is a pretty typical
> D library in terms of structure.

Thanks for testing!

Am 12.02.2014 16:40, schrieb Jordi Sayol:
> El 12/02/14 09:53, Sönke Ludwig ha escrit:
>> The binaries can be found on http://code.dlang.org/download ("Latest preview").
>
> On Debian 7.4 64-bit:
>
> $ dub
> dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dub)
>
>
> No problem on Debian 7.4 32-bit.
>

I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit, hopefully that works...

On Wednesday, 12 February 2014 at 18:06:19 UTC, Sönke Ludwig wrote:
> The latter. The target binaries of dependencies (recursively) are automatically linked against the final application.

Hm, I'm getting a failure to link, with just one symbol reported missing. Further, -allinst makes no difference. I checked the verbose output and the parent library was indeed being passed automatically when linking the example executable, so for now I assume it's a DMD/OPTLINK bug. I'll report back with more information if I can't reproduce it without Dub.

Really cool that libraries are automatically linked, I'm really liking how Dub is shaping up!

> Specifying linker search paths is not possible right now (at least some time ago this was problematic for DMD on Windows, not sure what the current state is). But specific library files can be added as `"sourceFiles"`. Those will be passed to the compiler at the linking stage, which passes them on to the linker.

Yeah, I remember OPTLINK being difficult in this regard. IIRC though, there is an environment variable one can set.

[1] https://github.com/JakobOvrum/LuaD/tree/master/example/hello

Am 12.02.2014 19:56, schrieb Jakob Ovrum:
> On Wednesday, 12 February 2014 at 18:06:19 UTC, Sönke Ludwig wrote:
>> The latter. The target binaries of dependencies (recursively) are
>> automatically linked against the final application.
>
> Hm, I'm getting a failure to link, with just one symbol reported
> missing. Further, -allinst makes no difference. I checked the verbose
> output and the parent library was indeed being passed automatically when
> linking the example executable, so for now I assume it's a DMD/OPTLINK
> bug. I'll report back with more information if I can't reproduce it
> without Dub.

I've reduced it and filed a bug:

https://d.puremagic.com/issues/show_bug.cgi?id=12144

It was actually great that this occurred in LuaD, because I suspect that I'm possibly hit by the same bug, but my code base is so large that it takes over a week to run dustmite on it.