DUB 0.9.21 beta 1

[Atila Neves]

The "bug" turned out to be me not using "importPaths" correctly, 
so my bad.

On Friday, 10 January 2014 at 18:48:11 UTC, Atila Neves wrote:
> I finally got around to cloning the git repo and trying the 
> latest dub and how dub test would work.
>
> 1st of all there is a bug, should I also add it to the issue 
> tracker on github? In any case, when the default "source" 
> directory isn't used but explicitly named in package.json, the 
> static imports in the autogenerated file don't have the library 
> name before the modules, i.e. instead of "static import 
> libname.modname" the it had "static import modname". I created 
> a git branch for testing purposes and moved my code to 
> "source", deleting "importPaths" and "sourcePaths" from the 
> package.json and the code generation worked with the right 
> static imports.
>
> The other problem I have for my use case is that, since I'm not 
> using the built-in unittest blocks for testing, I have testing 
> code that can't be "turned off" by omitting -unittest. So far 
> I've been using rdmd to figure out the test dependencies. With 
> the actual unit test code in a different directory, dub test 
> fails with a linker error. I don't know what the easiest way 
> would be to tell dub to also compile and link a list of 
> directories. Basically I need not only --main-file but also 
> something like --extra-dirs=dir1,dir2,dir3.
>
> Atila
>
>>> What exactly does "dub test" do? Is it like running "rdmd 
>>> -main
>>> -unittest foo.d"?
>>> 
>>
>> It's similar. By default, for library projects, it generates a 
>> maim
>> module of the form
>> ---
>> module test_main;
>> import <library_name.main_module>;
>> import std.stdio;
>> import core.runtime;
>>
>> void main() { writeln("All unit tests were successful."); }
>> ---
>> and runs it with build type "unittest".
>>
>> It also supports setting a custom file containing main(), so 
>> that for
>> example custom unit test runners can be specified and similar 
>> things. In
>> this case, the generated file looks like this:
>> ---
>> module test_main;
>> import <library_name.main_module>;
>> import <custom_main_module>;
>> ---
>>
>> For packages with only executable configurations it behaves 
>> the same as
>> "dub run --build=unittest".