DUB 0.9.21 beta 1

Atila Neves atila.neves at gmail.com
Fri Jan 10 10:48:10 PST 2014


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



More information about the Digitalmars-d-announce mailing list