www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DUB 0.9.20

reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
A fresh DUB release is out. Apart from the usual bug fixes, there are a
few considerable changes:

 - Builds are now cached and only rebuilt when necessary for "dub build"
   and "dub run".
 - Generated VisualD projects and the output of "dub describe" now
   contain import files and string import files in addition to pure
   source files.
 - Running "dub --build=ddox" runs a local HTTP server that provides
   the docs instead of generating them all as actual HTML files.
 - Pre-release versions of dependencies (e.g. 1.0.0-rc.1) are now only
   installed of nothing else matches the version expression, or if "dub
   upgrade --prerelease" is used. This is supposed to encourage the use
   of pre-release versions instead of just working with branches for
   released packages.
 - https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md

We also have now well over a hundred packages in the registry, 117 at
this point [1]!

Download at http://code.dlang.org/download


In the works for the next version is, among other things, a "dub test"
[2] command which executes unit tests (and possibly other kinds of tests
later) using a custom main() function, especially useful for automated
testing and testing of libraries without a main() function.

[1]: http://code.dlang.org
[2]: https://github.com/rejectedsoftware/dub/issues/83
Nov 29 2013
next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
New dub v0.9.20 deb packages available at:

d-apt <http://d-apt.sourceforge.net/>

-- 
Jordi Sayol
Nov 29 2013
parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote:

 New dub v0.9.20 deb packages available at:

 d-apt <http://d-apt.sourceforge.net/>


Thank you.
BTW, it would be great to have packages for previous DMD 
versions. You already support it for `libphobos2-nn` and almost 
for all other packages.
Nov 29 2013
parent reply Jordi Sayol <g.sayol yahoo.es> writes:
El 29/11/13 20:37, ilya-stromberg ha escrit:

 On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote:

 New dub v0.9.20 deb packages available at:

 d-apt <http://d-apt.sourceforge.net/>


 
 Thank you.
 BTW, it would be great to have packages for previous DMD versions. You already
support it for `libphobos2-nn` and almost for all other packages.
 


"libphobos2-nn" and other packages ending with "-nn" contains the shared
library necessary to run programs linked against them, so for this reason these
packages have version on its name, allowing to install multiple versions of the
same library.

Different case is "dmd" and development packages "-dev". Debian packaging
system do not allow to install multiple versions of the same package at same
time.

i.e. "dmd_2.064.2-0_amd64.deb" is newer version of "dmd_2.063.2-0_amd64.deb",
and upgrades it.
same with "libphobos2-dev_2.064.2_amd64.deb", which replaces
"libphobos2-dev_2.063.2_amd64.deb" by an upgrade.

To have multiple dmd versions on your system, you can use the Jacob Carlborg
project <https://github.com/jacob-carlborg/dvm>

Regards,
-- 
Jordi Sayol
Nov 29 2013
parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Friday, 29 November 2013 at 20:17:54 UTC, Jordi Sayol wrote:

 El 29/11/13 20:37, ilya-stromberg ha escrit:

 On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote:

 New dub v0.9.20 deb packages available at:

 d-apt <http://d-apt.sourceforge.net/>


 
 Thank you.
 BTW, it would be great to have packages for previous DMD 
 versions. You already support it for `libphobos2-nn` and 
 almost for all other packages.
 


 "libphobos2-nn" and other packages ending with "-nn" contains 
 the shared library necessary to run programs linked against 
 them, so for this reason these packages have version on its 
 name, allowing to install multiple versions of the same library.


OK, I see. Can we have different DMD packages with different DMD 
names? For example, can we have `dmd-63` and `dmd-64` at the same 
time? So, the `dmd` is simple alias to the latest DMD version. 
Sorry if I miss something, but it looks like possible solution.


 To have multiple dmd versions on your system, you can use the 
 Jacob Carlborg project <https://github.com/jacob-carlborg/dvm>


Yes, I know. But packages save some time.
Nov 29 2013
parent Jordi Sayol <g.sayol yahoo.es> writes:
El 29/11/13 21:54, ilya-stromberg ha escrit:

 On Friday, 29 November 2013 at 20:17:54 UTC, Jordi Sayol wrote:

 El 29/11/13 20:37, ilya-stromberg ha escrit:

 On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote:

 New dub v0.9.20 deb packages available at:

 d-apt <http://d-apt.sourceforge.net/>


 Thank you.
 BTW, it would be great to have packages for previous DMD versions. You already
support it for `libphobos2-nn` and almost for all other packages.


 "libphobos2-nn" and other packages ending with "-nn" contains the shared
library necessary to run programs linked against them, so for this reason these
packages have version on its name, allowing to install multiple versions of the
same library.


 
 OK, I see. Can we have different DMD packages with different DMD names? For
example, can we have `dmd-63` and `dmd-64` at the same time? So, the `dmd` is
simple alias to the latest DMD version. Sorry if I miss something, but it looks
like possible solution.


Is not the target of this repository.


 

 To have multiple dmd versions on your system, you can use the Jacob Carlborg
project <https://github.com/jacob-carlborg/dvm>


 
 Yes, I know. But packages save some time.
 


-- 
Jordi Sayol
Nov 29 2013
prev sibling next sibling parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-29 17:01:53 +0000, Sönke Ludwig said:

 
  - Builds are now cached and only rebuilt when necessary for "dub build"
    and "dub run".


Doesn't seem to be working correctly for me.  Won't rebuild after a 
build failure.
Nov 29 2013
parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 29.11.2013 21:27, schrieb Shammah Chancellor:

 On 2013-11-29 17:01:53 +0000, Sönke Ludwig said:

  - Builds are now cached and only rebuilt when necessary for "dub build"
    and "dub run".


 
 Doesn't seem to be working correctly for me.  Won't rebuild after a
 build failure.
 


Hm... there may be an issue when the linker fails, but leaves a
partially linked binary. I'll add some manual code that deletes the
result after the linker returns with an error.
Nov 29 2013
parent Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-29 22:39:33 +0000, Sönke Ludwig said:


 Am 29.11.2013 21:27, schrieb Shammah Chancellor:

 On 2013-11-29 17:01:53 +0000, Sönke Ludwig said:

 
 - Builds are now cached and only rebuilt when necessary for "dub build"
 and "dub run".


 
 Doesn't seem to be working correctly for me.  Won't rebuild after a
 build failure.
 


 
 Hm... there may be an issue when the linker fails, but leaves a
 partially linked binary. I'll add some manual code that deletes the
 result after the linker returns with an error.


I'll post an issue when I can isolate why it was doing it.   I can't 
seem to reproduce it now, but it was definitely doing it earlier.    It 
kept rerunning old binaries on me untill I made superfulous changes to 
files and re-saved.
Nov 29 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 29, 2013 18:01:53 Sönke Ludwig wrote:

  - Running "dub --build=ddox" runs a local HTTP server that provides
    the docs instead of generating them all as actual HTML files.


Why would that be desirable? I would expect a set of HTML files if generating 
documentation, and if a server is required to read the documentation instead 
of just bringing them up in your browser, that's a major usability problem 
IMHO. If ddox requires a server rather than just working with .html files, that 
would be a big reason for me to never use it.

- Jonathan M Davis
Nov 29 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 29.11.2013 23:05, schrieb Jonathan M Davis:

 On Friday, November 29, 2013 18:01:53 Sönke Ludwig wrote:

  - Running "dub --build=ddox" runs a local HTTP server that provides
    the docs instead of generating them all as actual HTML files.


 
 Why would that be desirable? I would expect a set of HTML files if generating 
 documentation, and if a server is required to read the documentation instead 
 of just bringing them up in your browser, that's a major usability problem 
 IMHO. If ddox requires a server rather than just working with .html files,
that 
 would be a big reason for me to never use it.
 
 - Jonathan M Davis
 


You can still use "dub build --build=ddox" to generate actual HTML
files, but using "run" it will simply skip the generation part and
displays the documentation much faster, depending on the size of the
project.
Nov 29 2013
parent Rory McGuire <rjmcguire gmail.com> writes:
On 30 Nov 2013 01:55, "S=C3=B6nke Ludwig" <sludwig outerproduct.org> wrote:

 Am 29.11.2013 23:05, schrieb Jonathan M Davis:

 On Friday, November 29, 2013 18:01:53 S=C3=B6nke Ludwig wrote:

  - Running "dub --build=3Dddox" runs a local HTTP server that provides
    the docs instead of generating them all as actual HTML files.


 Why would that be desirable? I would expect a set of HTML files if




generating

 documentation, and if a server is required to read the documentation




instead

 of just bringing them up in your browser, that's a major usability




problem

 IMHO. If ddox requires a server rather than just working with .html




files, that

 would be a big reason for me to never use it.

 - Jonathan M Davis


 You can still use "dub build --build=3Dddox" to generate actual HTML
 files, but using "run" it will simply skip the generation part and
 displays the documentation much faster, depending on the size of the
 project.


Great feature of you're working on docs. Probably awesome for bigger
projects.
Nov 30 2013
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there are a
 few considerable changes:


Thanks! Have you considered adding a version number to dub help and/or a 
--version option?
Nov 29 2013
parent reply Jordi Sayol <g.sayol yahoo.es> writes:
El 30/11/13 02:08, Piotr Szturmaj ha escrit:

 Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there are a
 few considerable changes:


 
 Thanks! Have you considered adding a version number to dub help and/or a
--version option?


$ dub help

prints version on last line:

....
DUB version v0.9.20

-- 
Jordi Sayol
Nov 29 2013
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Jordi Sayol wrote:

 El 30/11/13 02:08, Piotr Szturmaj ha escrit:

 Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there are a
 few considerable changes:


 Thanks! Have you considered adding a version number to dub help and/or a
--version option?


 $ dub help

 prints version on last line:

 ....
 DUB version v0.9.20


This is my dub help output (Windows): http://pastebin.com/0ENFz28V
Dec 02 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 02.12.2013 12:25, schrieb Piotr Szturmaj:

 Jordi Sayol wrote:

 El 30/11/13 02:08, Piotr Szturmaj ha escrit:

 Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there are a
 few considerable changes:


 Thanks! Have you considered adding a version number to dub help
 and/or a --version option?


 $ dub help

 prints version on last line:

 ....
 DUB version v0.9.20


 
 This is my dub help output (Windows): http://pastebin.com/0ENFz28V
 


Oh okay, that's for post-0.9.20. I've rewritten the command line
interface code and forgot to add this. Will do now.
Dec 02 2013
prev sibling next sibling parent reply "Puming" <zhaopuming gmail.com> writes:
On Friday, 29 November 2013 at 17:02:22 UTC, Sönke Ludwig wrote:


  - Builds are now cached and only rebuilt when necessary for 
 "dub build"
    and "dub run".


When I build a vibe project, and edit the app.d and then build 
again, an error occurs:

-------------
Checking dependencies in '/media/sf_github/dsp'
Error: Orphan format specifier: %File '%s' was modified in the 
future. Please re-save.
-------------

But after I do a `ls` command (or other commands) and then `dub` 
again, it went ok again.

Another thing to note is when app.d is modified, dub recompiles 
all the *.dt files, is that the case?
Nov 29 2013
parent reply "Puming" <zhaopuming gmail.com> writes:
On Saturday, 30 November 2013 at 02:16:50 UTC, Puming wrote:

 On Friday, 29 November 2013 at 17:02:22 UTC, Sönke Ludwig wrote:


 - Builds are now cached and only rebuilt when necessary for 
 "dub build"
   and "dub run".


 When I build a vibe project, and edit the app.d and then build 
 again, an error occurs:

 -------------
 Checking dependencies in '/media/sf_github/dsp'
 Error: Orphan format specifier: %File '%s' was modified in the 
 future. Please re-save.
 -------------


Sorry, this seems to be caused by a time problem in my share 
folder. please ignore it.


 But after I do a `ls` command (or other commands) and then 
 `dub` again, it went ok again.

 Another thing to note is when app.d is modified, dub recompiles 
 all the *.dt files, is that the case?


Does dub support increment compiling?
Nov 29 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 30.11.2013 03:21, schrieb Puming:

 On Saturday, 30 November 2013 at 02:16:50 UTC, Puming wrote:

 On Friday, 29 November 2013 at 17:02:22 UTC, Sönke Ludwig wrote:


 - Builds are now cached and only rebuilt when necessary for "dub build"
   and "dub run".


 When I build a vibe project, and edit the app.d and then build again,
 an error occurs:

 -------------
 Checking dependencies in '/media/sf_github/dsp'
 Error: Orphan format specifier: %File '%s' was modified in the future.
 Please re-save.
 -------------


 
 Sorry, this seems to be caused by a time problem in my share folder.
 please ignore it.
 


I've fixed the log message though, so it should read now just "File
'...' was modified in the future. Please re-save."


 But after I do a `ls` command (or other commands) and then `dub`
 again, it went ok again.

 Another thing to note is when app.d is modified, dub recompiles all
 the *.dt files, is that the case?


 
 Does dub support increment compiling?


This is planned, but (AFAIK) this is not yet possible in an optimal way
due to how DMD emits symbols to object files. Currently the only
reliable way to build incrementally is to compile a single file at a
time, but this is very inefficient compared to compiling multiple files
in one go.

A middle ground, which will be added in one of the next versions, is to
build and cache each dependency as a separate static library. But this
will still always build each complete package in one go, so all
templates as well.
Nov 29 2013
parent Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-30 02:58:50 +0000, Sönke Ludwig said:


 This is planned, but (AFAIK) this is not yet possible in an optimal way
 due to how DMD emits symbols to object files. Currently the only
 reliable way to build incrementally is to compile a single file at a
 time, but this is very inefficient compared to compiling multiple files
 in one go.


Can you even do this when templated symbols are defined in that file?  
This was horribly broken years ago as the templated symbols were 
emitted into the source file that the template was in, rather than the 
including file.
Nov 29 2013
prev sibling next sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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
Nov 30 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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?)
Nov 30 2013
parent =?UTF-8?B?IlPDtm5rZQ==?= Ludwig" <sludwig outerproduct.org> writes:
On Saturday, 30 November 2013 at 21:33:57 UTC, Dicebot wrote:

 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?)


No no, just a little preview to see if there are any further (or 
new) issues before the actual release.
Nov 30 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 01 2013
parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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".
Dec 02 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 02 2013
parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
Dec 02 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 02 2013
parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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).
Dec 02 2013
parent Jacob Carlborg <doob me.com> writes:
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
Dec 02 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 03 2013
parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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...>"
Dec 04 2013
parent Jacob Carlborg <doob me.com> writes:
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
Dec 04 2013
prev sibling next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
 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?
Dec 03 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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.
Dec 03 2013
prev sibling next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
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.
Dec 09 2013
parent reply "Kapps" <opantm2+spam gmail.com> writes:
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.
Dec 09 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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.");
}
---
Dec 11 2013
parent reply "Kapps" <opantm2+spam gmail.com> writes:
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.
Dec 11 2013
parent "Kapps" <opantm2+spam gmail.com> writes:
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).
Dec 11 2013
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
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".
Jan 10 2014
parent "Atila Neves" <atila.neves gmail.com> writes:
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".
Jan 12 2014
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 29/11/2013 17:01, Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there are a
 few considerable changes:


Quick question: is there a way to install/fetch the dependencies of a 
package, without having to build? That is, without using "dub build" ?


-- 
Bruno Medeiros - Software Engineer
Dec 03 2013
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 12/3/2013 9:47 PM, Bruno Medeiros wrote:

 On 29/11/2013 17:01, Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there are a
 few considerable changes:


 Quick question: is there a way to install/fetch the dependencies of a
 package, without having to build? That is, without using "dub build" ?


dub install packageName
Dec 03 2013
next sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 03/12/2013 13:00, Mike Parker wrote:

 On 12/3/2013 9:47 PM, Bruno Medeiros wrote:

 On 29/11/2013 17:01, Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there are a
 few considerable changes:


 Quick question: is there a way to install/fetch the dependencies of a
 package, without having to build? That is, without using "dub build" ?


 dub install packageName


That only works if packageName is a package in the DUB registry. It 
won't work for a locally created package.

-- 
Bruno Medeiros - Software Engineer
Dec 03 2013
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Tuesday, 3 December 2013 at 13:18:13 UTC, Bruno Medeiros wrote:

 That only works if packageName is a package in the DUB 
 registry. It won't work for a locally created package.


You can make dub aware of such a package with:

$ dub all-local . ~master

In which case, this particular package doesn't need to be 
dub-installed.
Dec 03 2013
parent "ponce" <contact gam3sfrommars.fr> writes:
 You can make dub aware of such a package with:

 $ dub all-local . ~master

 In which case, this particular package doesn't need to be 
 dub-installed.


I meant "add-local" not "all-local".
Dec 03 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 3 December 2013 at 13:00:06 UTC, Mike Parker wrote:

 On 12/3/2013 9:47 PM, Bruno Medeiros wrote:

 On 29/11/2013 17:01, Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, 
 there are a
 few considerable changes:


 Quick question: is there a way to install/fetch the 
 dependencies of a
 package, without having to build? That is, without using "dub 
 build" ?


 dub install packageName


It is `dub fetch` now, to remove common confusion. Alias to old 
name is preserved but undocumented.
Dec 03 2013
prev sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 03.12.2013 13:47, schrieb Bruno Medeiros:

 On 29/11/2013 17:01, Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there are a
 few considerable changes:


 
 Quick question: is there a way to install/fetch the dependencies of a
 package, without having to build? That is, without using "dub build" ?
 
 


"dub upgrade" should be the right call. Possibly with
"--root=path/to/package" or "dub upgrade pkgname:subpkgname
--root=path/to/package".
Dec 03 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 03/12/2013 13:44, Sönke Ludwig wrote:

 Am 03.12.2013 13:47, schrieb Bruno Medeiros:

 On 29/11/2013 17:01, Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there are a
 few considerable changes:


 Quick question: is there a way to install/fetch the dependencies of a
 package, without having to build? That is, without using "dub build" ?


 "dub upgrade" should be the right call. Possibly with
 "--root=path/to/package" or "dub upgrade pkgname:subpkgname
 --root=path/to/package".


It's not clear from the name, but yeah, does the trick!

-- 
Bruno Medeiros - Software Engineer
Dec 06 2013
parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 06.12.2013 13:57, schrieb Bruno Medeiros:

 On 03/12/2013 13:44, Sönke Ludwig wrote:

 Am 03.12.2013 13:47, schrieb Bruno Medeiros:

 On 29/11/2013 17:01, Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there are a
 few considerable changes:


 Quick question: is there a way to install/fetch the dependencies of a
 package, without having to build? That is, without using "dub build" ?


 "dub upgrade" should be the right call. Possibly with
 "--root=path/to/package" or "dub upgrade pkgname:subpkgname
 --root=path/to/package".


 
 It's not clear from the name, but yeah, does the trick!
 


The only use case that usually makes sense for it is to upgrade
packages. All other commands should implicitly fetch the required
packages, including "dub describe", so no explicit dependency fetching
is necessary.
Dec 06 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 06/12/2013 13:58, Sönke Ludwig wrote:

 Am 06.12.2013 13:57, schrieb Bruno Medeiros:

 On 03/12/2013 13:44, Sönke Ludwig wrote:

 Am 03.12.2013 13:47, schrieb Bruno Medeiros:

 On 29/11/2013 17:01, Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there are a
 few considerable changes:


 Quick question: is there a way to install/fetch the dependencies of a
 package, without having to build? That is, without using "dub build" ?


 "dub upgrade" should be the right call. Possibly with
 "--root=path/to/package" or "dub upgrade pkgname:subpkgname
 --root=path/to/package".


 It's not clear from the name, but yeah, does the trick!


 The only use case that usually makes sense for it is to upgrade
 packages. All other commands should implicitly fetch the required
 packages, including "dub describe", so no explicit dependency fetching
 is necessary.


'dub describe' is doing no such thing for me. Is that a bug?

-- 
Bruno Medeiros - Software Engineer
Dec 06 2013
parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 06.12.2013 16:39, schrieb Bruno Medeiros:

 On 06/12/2013 13:58, Sönke Ludwig wrote:

 Am 06.12.2013 13:57, schrieb Bruno Medeiros:

 On 03/12/2013 13:44, Sönke Ludwig wrote:

 Am 03.12.2013 13:47, schrieb Bruno Medeiros:

 On 29/11/2013 17:01, Sönke Ludwig wrote:

 A fresh DUB release is out. Apart from the usual bug fixes, there
 are a
 few considerable changes:


 Quick question: is there a way to install/fetch the dependencies of a
 package, without having to build? That is, without using "dub build" ?


 "dub upgrade" should be the right call. Possibly with
 "--root=path/to/package" or "dub upgrade pkgname:subpkgname
 --root=path/to/package".


 It's not clear from the name, but yeah, does the trick!


 The only use case that usually makes sense for it is to upgrade
 packages. All other commands should implicitly fetch the required
 packages, including "dub describe", so no explicit dependency fetching
 is necessary.


 
 'dub describe' is doing no such thing for me. Is that a bug?
 


Indeed, sorry, I didn't check that. It's fixed on git master.
Dec 06 2013
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 29 November 2013 at 17:02:22 UTC, Sönke Ludwig wrote:

  - Builds are now cached and only rebuilt when necessary for 
 "dub build"
    and "dub run".


Deleting the output binary and then immediately running `dub 
build` again fails horribly here; it seems to think the binary is 
up to date even though it doesn't even exist. (Windows/DMD/x86, 
library target)


 In the works for the next version is, among other things, a 
 "dub test"
 [2] command which executes unit tests (and possibly other kinds 
 of tests
 later) using a custom main() function, especially useful for 
 automated
 testing and testing of libraries without a main() function.


It has been said already in this thread, but for library targets 
it must ignore the lack of a "main source file". It should go 
without saying that libraries generally don't have such a thing.

---

Also, it would be nice if there was a way to output to a 
different target name for debug vs release builds of a library. 
It's quite common to have both live side-by-side, with the debug 
builds differentiated by a suffix -d or similar.

---

I added a couple of my projects to the package repository[1][2].

[1] http://code.dlang.org/packages/dirk
[2] http://code.dlang.org/packages/diggler
Dec 06 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 6 December 2013 at 18:40:59 UTC, Jakob Ovrum wrote:

 It has been said already in this thread, but for library 
 targets it must ignore the lack of a "main source file". It 
 should go without saying that libraries generally don't have 
 such a thing.


It adding such requirement for static libraries much of an issue? 
It provides quite lot of advantages. Though I guess dub can 
possibly generate such file on its own.
Dec 06 2013
next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 6 December 2013 at 18:55:22 UTC, Dicebot wrote:

 On Friday, 6 December 2013 at 18:40:59 UTC, Jakob Ovrum wrote:

 It has been said already in this thread, but for library 
 targets it must ignore the lack of a "main source file". It 
 should go without saying that libraries generally don't have 
 such a thing.


 It adding such requirement for static libraries much of an 
 issue? It provides quite lot of advantages. Though I guess dub 
 can possibly generate such file on its own.


It's unreasonable for Dub to require users to change the 
structure of their project, or add boilerplate to their project, 
for something as fundamental as building a simple static library.
Dec 06 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 6 December 2013 at 19:10:51 UTC, Jakob Ovrum wrote:

 It's unreasonable for Dub to require users to change the 
 structure of their project


It has been doing it since the very beginning and still does.
Dec 06 2013
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 6 December 2013 at 19:14:46 UTC, Dicebot wrote:

 On Friday, 6 December 2013 at 19:10:51 UTC, Jakob Ovrum wrote:

 It's unreasonable for Dub to require users to change the 
 structure of their project


 It has been doing it since the very beginning and still does.


How so?

In the very beginning it was much stricter, but it had the excuse 
that it was originally a vibe.d-specific utility. Once the scope 
of the project changed, we got additions like `sourcePaths` which 
made Dub support a much wider range of project structures.

It should be a no-brainer that Dub should impose as few 
restrictions on users as possible by letting them specify their 
project structure entirely in package.json.
Dec 06 2013
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 06.12.2013 20:10, schrieb Jakob Ovrum:

 On Friday, 6 December 2013 at 18:55:22 UTC, Dicebot wrote:

 On Friday, 6 December 2013 at 18:40:59 UTC, Jakob Ovrum wrote:

 It has been said already in this thread, but for library targets it
 must ignore the lack of a "main source file". It should go without
 saying that libraries generally don't have such a thing.


 It adding such requirement for static libraries much of an issue? It
 provides quite lot of advantages. Though I guess dub can possibly
 generate such file on its own.


 
 It's unreasonable for Dub to require users to change the structure of
 their project, or add boilerplate to their project, for something as
 fundamental as building a simple static library.


Just to get the facts straight, building a static library works without
a main file, just not when "--rdmd" is used. The only thing added in the
beta was the warning message.
Dec 06 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-06 19:55, Dicebot wrote:


 It adding such requirement for static libraries much of an issue? It
 provides quite lot of advantages. Though I guess dub can possibly
 generate such file on its own.


This might also cause modules to be more coupled with each other and 
causing more of the library being included then actually needed. Like 
what's happening with Phobos.

-- 
/Jacob Carlborg
Dec 06 2013
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 06.12.2013 19:40, schrieb Jakob Ovrum:

 On Friday, 29 November 2013 at 17:02:22 UTC, Sönke Ludwig wrote:

  - Builds are now cached and only rebuilt when necessary for "dub build"
    and "dub run".


 
 Deleting the output binary and then immediately running `dub build`
 again fails horribly here; it seems to think the binary is up to date
 even though it doesn't even exist. (Windows/DMD/x86, library target)


You need to delete the one in .dub/build/, the one in the target
directory is just a copy of that one. BTW there is now a "dub build
--force" switch, which forces a recompilation, and a "dub clean" command
will also be added later.


 

 In the works for the next version is, among other things, a "dub test"
 [2] command which executes unit tests (and possibly other kinds of tests
 later) using a custom main() function, especially useful for automated
 testing and testing of libraries without a main() function.


 
 It has been said already in this thread, but for library targets it must
 ignore the lack of a "main source file". It should go without saying
 that libraries generally don't have such a thing.


I'll work through that topic in the next days. If nothing requires it,
the warning will be removed and "dub test" will auto generate such a
file when needed.


 
 ---
 
 Also, it would be nice if there was a way to output to a different
 target name for debug vs release builds of a library. It's quite common
 to have both live side-by-side, with the debug builds differentiated by
 a suffix -d or similar.


They currently live in parallel in different sub folders of .dub/build/
and switching between different builds is just a matter of a single copy
of the target file, as long as the builds are up to date. I didn't yet
have issues with this approach, but on the other hand not much thought
has gone into this part, yet.
Dec 06 2013
next sibling parent reply Mathias Lang <pro.mathias.lang gmail.com> writes:
Great work, thank you S=F6nke !


2013/12/6 S=F6nke Ludwig <sludwig outerproduct.org>

 You need to delete the one in .dub/build/, the one in the target
 directory is just a copy of that one. BTW there is now a "dub build
 --force" switch, which forces a recompilation, and a "dub clean" command
 will also be added later.



Did you ever consider letting users add their own "recipe" (in Makefile
terminology).
ie, let them extend dub the same way you can extend git: one would put a
bash / D / FancyScriptLanguage script under [~/].dub/whatever/deploy, and
calling dub deploy would call that script, passing it the package.json data=
.



 Also, it would be nice if there was a way to output to a different



  > target name for debug vs release builds of a library. It's quite commo=


n

 to have both live side-by-side, with the debug builds differentiated by
 a suffix -d or similar.




That's something I found myself missing alot in D. Those little trick
aren't much of a pain to implement on the tool side, but they're definitely
a huge gain on the user side.
Dec 06 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-06 22:55, Mathias Lang wrote:


 Did you ever consider letting users add their own "recipe" (in Makefile
 terminology).
 ie, let them extend dub the same way you can extend git: one would put a
 bash / D / FancyScriptLanguage script under [~/].dub/whatever/deploy,
 and calling dub deploy would call that script, passing it the
 package.json data.


I think that would be nice to have.

-- 
/Jacob Carlborg
Dec 08 2013
prev sibling parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 06.12.2013 22:55, schrieb Mathias Lang:

 Great work, thank you Sönke !
 
 
 2013/12/6 Sönke Ludwig <sludwig outerproduct.org
 <mailto:sludwig outerproduct.org>>
 
     You need to delete the one in .dub/build/, the one in the target
     directory is just a copy of that one. BTW there is now a "dub build
     --force" switch, which forces a recompilation, and a "dub clean" command
     will also be added later. 
 
 
 Did you ever consider letting users add their own "recipe" (in Makefile
 terminology).
 ie, let them extend dub the same way you can extend git: one would put a
 bash / D / FancyScriptLanguage script under [~/].dub/whatever/deploy,
 and calling dub deploy would call that script, passing it the
 package.json data.


Incidentally, I've planned to look into something like this (for
deployment), too, a few days ago. In the beginning, there was also the
plan to provide a mode to run an external tool using "dub tool
<executable>". The tool would then receive a bunch of environment
variables that describe the current package.

But regarding the git-like extensibility, I'm not sure if it's not
better to let extensions rather be separate tools ("dub-deploy") to
avoid naming conflicts or backwards compatibility issues between the
core package and extensions.


  > Also, it would be nice if there was a way to output to a different
 
     > target name for debug vs release builds of a library. It's quite
     common
     > to have both live side-by-side, with the debug builds
     differentiated by
     > a suffix -d or similar.
 
 That's something I found myself missing alot in D. Those little trick
 aren't much of a pain to implement on the tool side, but they're
 definitely a huge gain on the user side.


Do you actually need to have both binaries at the same time in the same
directory, or would copying it there just before starting up the
application also be enough? I'm asking because there will probably be no
single schema that all people will be happy with and considering the
issues that arise from that, I'd rather avoid that feature if the same
goals can be achieved differently.
Dec 11 2013
prev sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 6 December 2013 at 19:57:17 UTC, Sönke Ludwig wrote:

 Am 06.12.2013 19:40, schrieb Jakob Ovrum:

 On Friday, 29 November 2013 at 17:02:22 UTC, Sönke Ludwig 
 wrote:

  - Builds are now cached and only rebuilt when necessary for 
 "dub build"
    and "dub run".


 
 Deleting the output binary and then immediately running `dub 
 build`
 again fails horribly here; it seems to think the binary is up 
 to date
 even though it doesn't even exist. (Windows/DMD/x86, library 
 target)


 You need to delete the one in .dub/build/, the one in the target
 directory is just a copy of that one. BTW there is now a "dub 
 build
 --force" switch, which forces a recompilation, and a "dub 
 clean" command
 will also be added later.


I actually tried `dub clean` as a guess, so that would be 
appreciated. But I have to say it's unintuitive behaviour 
compared to something like `make`. Users should not be concerned 
with the contents of a hidden directory. Deleting the output 
binary to force a rebuild is intuitive to me and probably a lot 
of other programmers. Perhaps just make it copy the up-to-date 
binary from the .dub/build directory to the output directory, 
displaying a note about it, possibly with a suggestion to use 
`dub clean`.


 They currently live in parallel in different sub folders of 
 .dub/build/
 and switching between different builds is just a matter of a 
 single copy
 of the target file, as long as the builds are up to date. I 
 didn't yet
 have issues with this approach, but on the other hand not much 
 thought
 has gone into this part, yet.


Tools like makefiles, IDE project files and indeed Dub itself 
cannot depend on the contents of the .dub/build directory. Having 
them exist in parallel is only useful for dependency management 
if they can actually be referenced.

"Switching between the builds" is not useful when the whole point 
is that they should be able to exist at the same time, so that 
debug builds can use debug binaries, and release builds use 
release binaries, without any non-trivial fuzz in between such as 
copying, which is a royal pain with many tools when you're trying 
to write platform-independent projects.

Is there a particular reason why `targetName` doesn't support 
suffixes? And is there a suffix to differentiate between debug 
and release builds? I currently have no idea how Dub deals with 
the debug/release distinction at all, I can't find any 
documentation for it.
Dec 09 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 09.12.2013 17:52, schrieb Jakob Ovrum:

 On Friday, 6 December 2013 at 19:57:17 UTC, Sönke Ludwig wrote:

 Am 06.12.2013 19:40, schrieb Jakob Ovrum:

 On Friday, 29 November 2013 at 17:02:22 UTC, Sönke Ludwig wrote:

  - Builds are now cached and only rebuilt when necessary for "dub
 build"
    and "dub run".


 Deleting the output binary and then immediately running `dub build`
 again fails horribly here; it seems to think the binary is up to date
 even though it doesn't even exist. (Windows/DMD/x86, library target)


 You need to delete the one in .dub/build/, the one in the target
 directory is just a copy of that one. BTW there is now a "dub build
 --force" switch, which forces a recompilation, and a "dub clean" command
 will also be added later.


 
 I actually tried `dub clean` as a guess, so that would be appreciated.
 But I have to say it's unintuitive behaviour compared to something like
 `make`. Users should not be concerned with the contents of a hidden
 directory. Deleting the output binary to force a rebuild is intuitive to
 me and probably a lot of other programmers. Perhaps just make it copy
 the up-to-date binary from the .dub/build directory to the output
 directory, displaying a note about it, possibly with a suggestion to use
 `dub clean`.


The current GIT master version now outputs a clearer message, stating
that the existing binary from ".dub/build/.../" is used. It also
suggests to use "--force" to force a rebuild.


 

 They currently live in parallel in different sub folders of .dub/build/
 and switching between different builds is just a matter of a single copy
 of the target file, as long as the builds are up to date. I didn't yet
 have issues with this approach, but on the other hand not much thought
 has gone into this part, yet.


 
 Tools like makefiles, IDE project files and indeed Dub itself cannot
 depend on the contents of the .dub/build directory. Having them exist in
 parallel is only useful for dependency management if they can actually
 be referenced.


The .dub/build/ folder is purely meant for DUB's built-in build system
(maybe a better name would be "cache" or "build-cache"). IDE projects
and external tools shouldn't ever look at it. The final build result
will be located in the specified "targetPath", which is where every
other entity except the build system should expect it.


 
 "Switching between the builds" is not useful when the whole point is
 that they should be able to exist at the same time, so that debug builds
 can use debug binaries, and release builds use release binaries, without
 any non-trivial fuzz in between such as copying, which is a royal pain
 with many tools when you're trying to write platform-independent projects.


I don't get this. The copying will be done by dub automatically and IDE
projects will usually use their own way of storing different build type
results. Are there any other tools you are thinking about which depend
on the presence of multiple build types?


 
 Is there a particular reason why `targetName` doesn't support suffixes?
 And is there a suffix to differentiate between debug and release builds?
 I currently have no idea how Dub deals with the debug/release
 distinction at all, I can't find any documentation for it.


They are just different "build types" which pass different flags to the
compiler. Everything else stays the same. The build cache is briefly
described in
https://github.com/rejectedsoftware/dub/wiki/Separate-compilation-and-caching-of-dependencies
- but assuming it does its job right, it shouldn't change the semantics
of the (re)build process.

Regarding the suffixes (or pre-/infixes), the foremost issue is how to
suit everyone's taste ("d"/"debug"/"dbg") without going crazy for the
required configuration on package.json. That plus that I haven't yet
understood why this is really needed to solve the problem. I'd by far
prefer a simple (to the outside) solution that "just works" without any
required configuration.
Dec 11 2013
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 11 December 2013 at 09:47:27 UTC, Sönke Ludwig 
wrote:

 The current GIT master version now outputs a clearer message, 
 stating
 that the existing binary from ".dub/build/.../" is used. It also
 suggests to use "--force" to force a rebuild.


Nice.


 The .dub/build/ folder is purely meant for DUB's built-in build 
 system
 (maybe a better name would be "cache" or "build-cache"). IDE 
 projects
 and external tools shouldn't ever look at it. The final build 
 result
 will be located in the specified "targetPath", which is where 
 every
 other entity except the build system should expect it.


That was exactly my point. They need to be able to live 
side-by-side in the targetPath directory. You replied and told me 
they do live side-by-side in the cache directory, which I don't 
think is relevant.


 I don't get this. The copying will be done by dub automatically 
 and IDE
 projects will usually use their own way of storing different 
 build type
 results. Are there any other tools you are thinking about which 
 depend
 on the presence of multiple build types?


 From your reply I assumed you meant adding something like a 
post-build command to copy the debug binary from the .dub/build/ 
directory to the targetPath directory if I wanted to have both 
release and debug binaries exist in targetPath simultaneously.

Consider a simple makefile that depends on 
dependency/lib/libname.a for release builds and 
dependency/lib/lib/libname-d.a for debug builds, or an IDE 
project that's configured similarly, or a zip script that needs 
to include both etc. The scenarios are endless, it's quite common 
practice.


 They are just different "build types" which pass different 
 flags to the
 compiler. Everything else stays the same. The build cache is 
 briefly
 described in
 https://github.com/rejectedsoftware/dub/wiki/Separate-compilation-and-caching-of-dependencies
 - but assuming it does its job right, it shouldn't change the 
 semantics
 of the (re)build process.


Right, if there was a build-type suffix and targetName supported 
it, I could do:

"targetName-debug": "mylib-d"


 Regarding the suffixes (or pre-/infixes), the foremost issue is 
 how to
 suit everyone's taste ("d"/"debug"/"dbg") without going crazy 
 for the
 required configuration on package.json. That plus that I 
 haven't yet
 understood why this is really needed to solve the problem. I'd 
 by far
 prefer a simple (to the outside) solution that "just works" 
 without any
 required configuration.


A reasonable default helps with the "just works" factor for new 
projects, but existing projects need the suffix to be 
configurable so it can be backwards-compatible. It's also more 
practical to let users choose what suffix to use rather than 
pursuing the "ultimate" suffix for satisfying users' taste.
Dec 11 2013
prev sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig+dforum outerproduct.org> writes:
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.
Jan 15 2014
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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
Jan 26 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
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
Jan 27 2014
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
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
Jan 27 2014
parent "eles" <eles eles.com> writes:
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?
Jan 27 2014
prev sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
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.
Jan 27 2014