DUB 0.9.21 beta 1

Sönke Ludwig sludwig at outerproduct.org
Mon Dec 2 12:51:00 PST 2013


Am 02.12.2013 17:01, schrieb Jacob Carlborg:
> On 2013-12-02 10:10, Sönke Ludwig wrote:
> 
>> It errors out. An alternative would be to put _all_ source files as
>> static imports into the generated module, but the main file will also be
>> required for dependency based builds (--rdmd and possibly for DUB's own
>> build system, once partial rebuilds work), so I figured it would be a
>> good idea to already add it now and make sure that most projects have
>> one when/if it gets important.
> 
> I don't know why a main module is required for libraries in the first
> place. It doesn't make sense. It's perfectly fine to have a library
> consisting of two files which don't import each other. This must be
> supported.
> 
> To me, for libraries, it would make most sense to just specify a
> directory and it would compile all those files in that directory.

I need to dig up the old discussions about this topic, I just seemed to
remember that we reached a conclusion to require a root file also for
libraries, but you are right that technically it's not required in this
case (as in the the suggested alternative).

> 
>> Using "dub test --main-file=...". See also "dub test --help".
> 
> I see.
> 
>> Unit tests in a separate folder can for example have their own package
>> description file and be handled separately. But "dub test" like it is
>> now is just the minimal beginning, everything else still needs to be
>> figured out/defined, ideas and opinions are welcome.
> 
> For any testing tool worthy its name I would at least expect to be able
> to use it like this:
> 
> $ dub test ./directory
> 
> Runs all test in the given directory, recursively

$ dub test --root=./directory

This doesn't work recursively, but a --recursive switch may be a good
idea to add.

> 
> $ dub test foo.d
> 
> Runs all test in the given file
> 

Since DUB operates on packages and I don't really see the compelling
advantage over "rdmd -main -unittest foo.d", I'd rather not complicate
it further for this use case. An exception would be if foo is a single
file package (yet to be implemented).



More information about the Digitalmars-d-announce mailing list