Re: DUB 0.9.21
On Saturday, 22 February 2014 at 09:44:48 UTC, Sönke Ludwig wrote: A new final release is ready. This one took a bit longer and has more changes than usual: After updating, to 0.9.21 dub generate visuald no longer generates release and unittestconfigurations for VisualD - only debug is available. I downgraded to 0.9.20 to make sure and indeed this version generates VisualD projects correctly (with all 3 configurations)
Re: DUB 0.9.21
Am 22.02.2014 13:07, schrieb Sönke Ludwig: Am 22.02.2014 12:24, schrieb Paulo Pinto: Am 22.02.2014 10:44, schrieb Sönke Ludwig: The Windows installer seems not to like being installed via UAC as the Administrator gets the PATH configured, not the user that started the installer. -- Paulo Going by the installer script, it should install to the global PATH (HKEY_LOCAL_MACHINE) variable, not to the user's (or Adminstrator's) one. Are you sure that the latter is the case for you? There is also a ticket to enable per-user installation from unprivileged accounts. I'll try to look into that topic, too, for the next release (need to read up on the proper NSIS options/plugins). Forget my previous post. Apparently it required a reboot to update the user's environment. Thanks again for the good work. -- Paulo
Re: DUB 0.9.21
On 02/22/2014 10:44 AM, Sönke Ludwig wrote: A new final release is ready. This one took a bit longer and has more changes than usual: (...) Thanks for what looks like a great release! The second feature planned is first class support for Dustmite - (...) Mostly welcomed. Dustmite is really great, but every time I use it I have to read the documentation and try/fail some.
Re: DUB 0.9.21
On 2/22/2014 6:44 PM, Sönke Ludwig wrote: A new final release is ready. This one took a bit longer and has more changes than usual: Great job! Thanks for all the work you're putting into this.
Re: DUB 0.9.21
Thanks for the great work! On Saturday, 22 February 2014 at 09:44:48 UTC, Sönke Ludwig wrote: A new final release is ready. This one took a bit longer and has more changes than usual
Re: DUB 0.9.21
https://www.archlinux.org/packages/community/x86_64/dub/
Re: DUB 0.9.21
Am 22.02.2014 10:44, schrieb Sönke Ludwig: A new final release is ready. This one took a bit longer and has more changes than usual: - Finally properly obeys the difference between target types library, staticLibrary, dynamicLibrary and sourceLibrary. By default, each library type dependency is now build as a static library. The building it combined with the parent package (as in previous versions) can be achieved using the --combined switch. - The preferred package description file name is now dub.json instead of the historically grown package.json to avoid ambiguities (NPM, for example, also uses package.json). - A new dub test command can now be used to run the unit tests of any package. DUB will automatically replace the main() of the package with a custom one (if any, see also mainSourceFile [1]). - The ~ pessimistic version operator as known from RubyGems [2] is now supported and recommended as the default operator to use. - Path based sub packages are now supported and recommended over the use of multiple sub packages per directory due to the potential pitfalls of overlapping import paths [3]. - Revamped command line help - you can now run dub command -h to get more detailed, command specific help - All changes: https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md#v0921---2014-02-22 Download at http://code.dlang.org/download Planned for the next release (which will be a much smaller one) is a major overhaul of how branch based (as opposed to tagged version based) dependencies are handled. Please see the corresponding thread and share your thoughts if you think anything should be improved [4]. The second feature planned is first class support for Dustmite - creating a reduced test case for an error in a multi-package project will then usually be as simple as invoking dub dustmite with a regular expression matched against the compiler/linker/program output. DUB will take care of copying together all sources and issuing the proper Dustmite command, calling itself in a special low overhead mode to speed up the process. This has already been used to great effect for reporting regressions during the DMD 2.065 beta phase, which would otherwise not have been possible due to a serious lack of time on my part (running Dustmite across multiple DUB packages otherwise requires some non-trivial preparation of of the source directory structure). [1]: http://code.dlang.org/package-format#build-settings [2]: http://robots.thoughtbot.com/rubys-pessimistic-operator [3]: http://code.dlang.org/package-format#sub-packages [4]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1020/ PS: The package registry now almost reached 200 available packages (191 as of this writing) Great job, integrating it into my hobby projects.
Re: DUB 0.9.21
Am 22.02.2014 10:44, schrieb Sönke Ludwig: A new final release is ready. This one took a bit longer and has more changes than usual: - Finally properly obeys the difference between target types library, staticLibrary, dynamicLibrary and sourceLibrary. By default, each library type dependency is now build as a static library. The building it combined with the parent package (as in previous versions) can be achieved using the --combined switch. - The preferred package description file name is now dub.json instead of the historically grown package.json to avoid ambiguities (NPM, for example, also uses package.json). - A new dub test command can now be used to run the unit tests of any package. DUB will automatically replace the main() of the package with a custom one (if any, see also mainSourceFile [1]). - The ~ pessimistic version operator as known from RubyGems [2] is now supported and recommended as the default operator to use. - Path based sub packages are now supported and recommended over the use of multiple sub packages per directory due to the potential pitfalls of overlapping import paths [3]. - Revamped command line help - you can now run dub command -h to get more detailed, command specific help - All changes: https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md#v0921---2014-02-22 Download at http://code.dlang.org/download Planned for the next release (which will be a much smaller one) is a major overhaul of how branch based (as opposed to tagged version based) dependencies are handled. Please see the corresponding thread and share your thoughts if you think anything should be improved [4]. The second feature planned is first class support for Dustmite - creating a reduced test case for an error in a multi-package project will then usually be as simple as invoking dub dustmite with a regular expression matched against the compiler/linker/program output. DUB will take care of copying together all sources and issuing the proper Dustmite command, calling itself in a special low overhead mode to speed up the process. This has already been used to great effect for reporting regressions during the DMD 2.065 beta phase, which would otherwise not have been possible due to a serious lack of time on my part (running Dustmite across multiple DUB packages otherwise requires some non-trivial preparation of of the source directory structure). [1]: http://code.dlang.org/package-format#build-settings [2]: http://robots.thoughtbot.com/rubys-pessimistic-operator [3]: http://code.dlang.org/package-format#sub-packages [4]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1020/ PS: The package registry now almost reached 200 available packages (191 as of this writing) The Windows installer seems not to like being installed via UAC as the Administrator gets the PATH configured, not the user that started the installer. -- Paulo
Re: DUB 0.9.21
Congratulations for this new dub release. Already uploaded new dub deb packages for this release at http://d-apt.sourceforge.net/ -- Jordi Sayol
Re: DUB 0.9.21
Am 22.02.2014 12:24, schrieb Paulo Pinto: Am 22.02.2014 10:44, schrieb Sönke Ludwig: The Windows installer seems not to like being installed via UAC as the Administrator gets the PATH configured, not the user that started the installer. -- Paulo Going by the installer script, it should install to the global PATH (HKEY_LOCAL_MACHINE) variable, not to the user's (or Adminstrator's) one. Are you sure that the latter is the case for you? There is also a ticket to enable per-user installation from unprivileged accounts. I'll try to look into that topic, too, for the next release (need to read up on the proper NSIS options/plugins).
Re: DUB 0.9.21
On Saturday, 22 February 2014 at 12:07:39 UTC, Sönke Ludwig wrote: Am 22.02.2014 12:24, schrieb Paulo Pinto: Am 22.02.2014 10:44, schrieb Sönke Ludwig: The Windows installer seems not to like being installed via UAC as the Administrator gets the PATH configured, not the user that started the installer. -- Paulo Going by the installer script, it should install to the global PATH (HKEY_LOCAL_MACHINE) variable, not to the user's (or Adminstrator's) one. Are you sure that the latter is the case for you? There is also a ticket to enable per-user installation from unprivileged accounts. I'll try to look into that topic, too, for the next release (need to read up on the proper NSIS options/plugins). Just installed on my win7 machine without problems, on win8 on the other hand authorization was required... strange
Re: DUB 0.9.21 beta 3
Am 27.01.2014 04:33, schrieb Jakob Ovrum: On Wednesday, 15 January 2014 at 14:12:47 UTC, Sönke Ludwig wrote: A new and hopefully last beta version of DUB 0.9.21 has been released: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/826/ It contains some major new features, so extensive testing is needed to get a solid release. When using dub-test on one of my projects, I'm getting: dub_test_root.d(15): Error: module deimos.ev from file libev\deimos\ev.d must be imported as module 'deimos.ev' dub_test_root appears to import it as `libev.deimos.ev`, which is wrong. It looks like it should instead be looking at the module statement for how to import. The dub.json and project hierarchy can be found here[1]. [1] https://github.com/JakobOvrum/Dirk I think there are two possibilities to solve this: - Like you already suggested, use the module statement of each file. This, however, will require to read and parse every source file - something which isn't required so far and I'd like to avoid that, if possible. Also, using the module statement will also not work in general, if not all files are compiled on the same compiler command line. - Use the closest matching import folder to infer the module name instead of the first match (i.e. ./libev instead of . in this case). However, apart from this, this (quite popular) kind of file structure really is a pet peeve of mine. Anyone who uses the library can now do things like import irc.client; // good import deimos.ev; // bad - conflicts with any library that uses the // libev DUB package import libev.deimos.ev; // bad - conflicts with the module statement import loader.windows; // bad - likely conflicts with other libraries I understand that it is popular because a separate source or src folder can be avoided*. But it really is quite unclean considering how importing modules works in D. * and it makes it harder for people to find the actual source code
Re: DUB 0.9.21 beta 3
Am 27.01.2014 13:14, schrieb Sönke Ludwig: - Use the closest matching import folder to infer the module name instead of the first match (i.e. ./libev instead of . in this case). Implemented: https://github.com/rejectedsoftware/dub/commit/5d0867fef7c6415e300c6ce214aa5790d0a2ca93
Re: DUB 0.9.21 beta 3
On Monday, 27 January 2014 at 12:38:06 UTC, Sönke Ludwig wrote: Am 27.01.2014 13:14, schrieb Sönke Ludwig: - Use the closest matching import folder to infer the module name instead of the first match (i.e. ./libev instead of . in this case). Implemented: https://github.com/rejectedsoftware/dub/commit/5d0867fef7c6415e300c6ce214aa5790d0a2ca93 Would it be reasonable to add dub edit to automatically edit the package/dub.json file?
Re: DUB 0.9.21 beta 3
On Monday, 27 January 2014 at 12:14:37 UTC, Sönke Ludwig wrote: I understand that it is popular because a separate source or src folder can be avoided*. But it really is quite unclean considering how importing modules works in D. * and it makes it harder for people to find the actual source code Yes, I agree. Dirk was the last project I created that uses this hierarchy (created in November 2010). It's a problem of scalability - the `libev`, `ssl` and `loader` packages were added long after the `irc` package.
Re: DUB 0.9.21 beta 3
On Wednesday, 15 January 2014 at 14:12:47 UTC, Sönke Ludwig wrote: A new and hopefully last beta version of DUB 0.9.21 has been released: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/826/ It contains some major new features, so extensive testing is needed to get a solid release. When using dub-test on one of my projects, I'm getting: dub_test_root.d(15): Error: module deimos.ev from file libev\deimos\ev.d must be imported as module 'deimos.ev' dub_test_root appears to import it as `libev.deimos.ev`, which is wrong. It looks like it should instead be looking at the module statement for how to import. The dub.json and project hierarchy can be found here[1]. [1] https://github.com/JakobOvrum/Dirk
Re: DUB 0.9.21 beta 1
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.
Re: DUB 0.9.21 beta 1
Am 09.12.2013 18:29, schrieb Kapps:
On Monday, 9 December 2013 at 12:46:00 UTC, Kapps wrote:
I was looking for something similar to dub test and am glad to see it
added, but I can't seem to figure out how to get it to do anything at
all.
Okay, it seems that this was just an issue with the beta. Building from
git master allows me to run dub test on an executable or a library
that has a main function within app.d. It would be nice to have an
automated way of running unit tests for all modules within a library
with a main file automatically generated. Even more awesome if there was
a way to integrate with tested to perform the tests. Perhaps for the
latter I could determine all files in the library with dub describe,
generate an app.d that calls tested's unit test runner on each, and then
put that app.d inside the library's source folder before invoking dub test.
The latest GIT master version now works without requiring a main file.
Regarding integration with tested, what should work now is to import
the automatically generated module test_main and use that as the
testing root:
---
import test_main;
shared static this()
{
import core.runtime;
Runtime.moduleUnitTester = () = true;
}
void main()
{
enforce(runUnitTests!test_main(new ConsoleTestResultWriter), Unit
tests failed.);
}
---
Re: DUB 0.9.21 beta 1
On Wednesday, 11 December 2013 at 09:51:37 UTC, Sönke Ludwig
wrote:
The latest GIT master version now works without requiring a
main file.
Regarding integration with tested, what should work now is to
import
the automatically generated module test_main and use that as
the
testing root:
Awesome. :)
I noticed that the main file generated seems to already support
tested integration automatically which I find quite nice.
Unfortunately it seems that tested is not actually following
imports so both the above sample and the auto-generated main
result in 0 tests being run as test_main does not directly
contain any tests. I've tried looking in to fixing this, but it's
proving a bit more tricky than expected and I won't have much
time for the next couple of days. Essentially, with static if
(__traits(compiles, { auto tup = TypeTuple!(__traits(getMember,
composite, M)); })) I don't believe that that's ever true as
assigning to tup like that is an error. Changing that to check if
the getMember succeeds will then get past that, but now the
recursive calls for runUnitTestsImpl will operate on the return
type of methods as __traits(getMember, T, somemethod) returns
the result of invoking the method and not the method itself. I'm
not sure how to pass in an alias to the actual method rather than
to the return type.
Re: DUB 0.9.21 beta 1
On Wednesday, 11 December 2013 at 22:13:59 UTC, Kapps wrote:
I noticed that the main file generated seems to already support
tested integration automatically which I find quite nice.
Unfortunately it seems that tested is not actually following
imports so both the above sample and the auto-generated main
result in 0 tests being run as test_main does not directly
contain any tests. I've tried looking in to fixing this, but
it's proving a bit more tricky than expected and I won't have
much time for the next couple of days. Essentially, with
static if (__traits(compiles, { auto tup =
TypeTuple!(__traits(getMember, composite, M)); })) I don't
believe that that's ever true as assigning to tup like that is
an error. Changing that to check if the getMember succeeds will
then get past that, but now the recursive calls for
runUnitTestsImpl will operate on the return type of methods as
__traits(getMember, T, somemethod) returns the result of
invoking the method and not the method itself. I'm not sure how
to pass in an alias to the actual method rather than to the
return type.
Ah, I think I'm mistaken. What I assumed was that it was handling
the return type of the function may have just been that it was
going over aliases instead (which in this case would have been an
alias to ulong and such, causing the above problems).
Re: DUB 0.9.21 beta 1
I was looking for something similar to dub test and am glad to see it added, but I can't seem to figure out how to get it to do anything at all. In particular, I'm trying to give tested a try as it seems quite nice and I was looking for an automated way to generate computer-readable test results (results.json in this case). According to the github page for tested, with the latest version of dub (I'm using the beta version in OSX) I should just be able to add tested as a dependency and run dub test to generate test results. I created a package called dubtest, and set app.d to contain just a unittest with @name set from tested. I then run dub test, and get: Got library for false Checking dependencies in '/Users/kapps/dev/src/dubtest' Running unit tests for package dubtest, configuration 'library'. Package dubtest (configuration library) defines no main source file, this may cause certain build modes to fail. Add an explicit mainSourceFile to the package description to fix this. Error executing command test: Main source file not found in any import path. I also tried giving my app.d a void main() which has the same result. I also tried dub test dubtest --main-file=main.d where main.d just contains a void main and writeln, but this has the same result as well. If I specifically set targetType to executable in package.json and run dub test, then I get: Got for false Building package dubtest in /Users/kapps/dev/src/dubtest Got for false Checking dependencies in '/Users/kapps/dev/src/dubtest' Running unit tests for package dubtest, configuration ''. Error executing command test: Could not resolve configuration for package tested If I use dub --build=unittest however while it's set to executable, it will successfully build and reach my main (or give a linker error if no main is present / targetType is not executable). Overall, I can't seem to get dub test to work at all regardless of configuration. Ideally I'm looking for a way to have tested run my unittests and output a results.json without manually creating a main file since these projects are generally libraries and I'm trying to automate the process for continuous integration purposes.
Re: DUB 0.9.21 beta 1
On Monday, 9 December 2013 at 12:46:00 UTC, Kapps wrote: I was looking for something similar to dub test and am glad to see it added, but I can't seem to figure out how to get it to do anything at all. Okay, it seems that this was just an issue with the beta. Building from git master allows me to run dub test on an executable or a library that has a main function within app.d. It would be nice to have an automated way of running unit tests for all modules within a library with a main file automatically generated. Even more awesome if there was a way to integrate with tested to perform the tests. Perhaps for the latter I could determine all files in the library with dub describe, generate an app.d that calls tested's unit test runner on each, and then put that app.d inside the library's source folder before invoking dub test.
Re: DUB 0.9.21 beta 1
Am 03.12.2013 19:52, schrieb Jacob Carlborg: On 2013-12-02 10:10, Sönke Ludwig wrote: Using dub test --main-file= See also dub test --help. * Can this be specified in the package.json file so invoking dub test will always use a custom main file? Not in a nice way, but I'd suggest we do something like making dub test look for a configuration named unittest before trying to generate its own custom main. * Don't know how it works now but it would be nice if dub could pass all remaining command line arguments to the custom main function It does already: dub test -- args...
Re: DUB 0.9.21 beta 1
On 2013-12-04 10:57, Sönke Ludwig wrote: Not in a nice way, but I'd suggest we do something like making dub test look for a configuration named unittest before trying to generate its own custom main. That would be nice to have. It does already: dub test -- args... Cool. -- /Jacob Carlborg
Re: DUB 0.9.21 beta 1
It also supports setting a custom file containing main(), so that for example custom unit test runners can be specified and similar Awesome! 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. So custom_main_module defines the main function to be executed?
Re: DUB 0.9.21 beta 1
Am 03.12.2013 10:34, schrieb Atila Neves: It also supports setting a custom file containing main(), so that for example custom unit test runners can be specified and similar Awesome! 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. So custom_main_module defines the main function to be executed? Exactly. main() will usually be empty, as unit tests by default run before main() is called, but it can be used to disable the standard Runtime.moduleUnitTester and do something customized.
Re: DUB 0.9.21 beta 1
On 2013-12-02 10:10, Sönke Ludwig wrote: Using dub test --main-file= See also dub test --help. * Can this be specified in the package.json file so invoking dub test will always use a custom main file? * Don't know how it works now but it would be nice if dub could pass all remaining command line arguments to the custom main function -- /Jacob Carlborg
Re: DUB 0.9.21 beta 1
Am 02.12.2013 08:32, schrieb Jacob Carlborg:
On 2013-11-30 21:48, Sönke Ludwig wrote:
Based on the bug reports so far, I've prepared a new beta release of
0.9.21 for testing. Apart from fixes for the reported issues, it
contains a revamped command line interface with detailed help for each
command and also the new dub test command.
http://code.dlang.org/download
https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md
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.
Re: DUB 0.9.21 beta 1
On 2013-12-02 09:10, Sönke Ludwig wrote:
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.
What if there isn't a main module for the library?
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;
---
How is the custom file specified?
For packages with only executable configurations it behaves the same as
dub run --build=unittest.
This doesn't support having the unit tests in a separate folder?
--
/Jacob Carlborg
Re: DUB 0.9.21 beta 1
Am 02.12.2013 09:19, schrieb Jacob Carlborg:
On 2013-12-02 09:10, Sönke Ludwig wrote:
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.
What if there isn't a main module for the library?
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.
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;
---
How is the custom file specified?
Using dub test --main-file= See also dub test --help.
For packages with only executable configurations it behaves the same as
dub run --build=unittest.
This doesn't support having the unit tests in a separate folder?
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.
Re: DUB 0.9.21 beta 1
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. 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 foo.d Runs all test in the given file -- /Jacob Carlborg
Re: DUB 0.9.21 beta 1
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).
Re: DUB 0.9.21 beta 1
On 2013-12-02 21:51, Sönke Ludwig wrote: 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). Please let me know if you find it. 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). Fair enough. -- /Jacob Carlborg
Re: DUB 0.9.21 beta 1
On 2013-11-30 21:48, Sönke Ludwig wrote: Based on the bug reports so far, I've prepared a new beta release of 0.9.21 for testing. Apart from fixes for the reported issues, it contains a revamped command line interface with detailed help for each command and also the new dub test command. http://code.dlang.org/download https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md What exactly does dub test do? Is it like running rdmd -main -unittest foo.d? -- /Jacob Carlborg
Re: DUB 0.9.21 beta 1
Based on the bug reports so far, I've prepared a new beta release of 0.9.21 for testing. Apart from fixes for the reported issues, it contains a revamped command line interface with detailed help for each command and also the new dub test command. http://code.dlang.org/download https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md
Re: DUB 0.9.21 beta 1
On Saturday, 30 November 2013 at 20:49:14 UTC, Sönke Ludwig wrote: Based on the bug reports so far, I've prepared a new beta release of 0.9.21 for testing. Apart from fixes for the reported issues, it contains a revamped command line interface with detailed help for each command and also the new dub test command. http://code.dlang.org/download https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md So, is it beta or release? :) (Should I package it already?)
