Re: DUB test and strings that look like D code
The analysis is pretty brain dead. https://github.com/dlang/dub/blob/master/source/dub/internal/utils.d#L611
DUB test and strings that look like D code
Is it just me, or does this happen for someone else, too?
Init a fresh DUB project and create a file (e.g. `lib.d`) with
the following content:
```d
unittest {
string x = "module oh.dear.dub.what.are.you.doing;";
}
```
Then run `dub test`:
```
.dub/code/foo-test-library-unittest-linux.posix-x86_64-ldc_v1.31.0-E3344CC6C11D674C408FBF98D8EEFA551F60B915102F9E22FF0F316715677AD5/dub_test_root.d(3,15):
Error: unable to read module `doing`
.dub/code/foo-test-library-unittest-linux.posix-x86_64-ldc_v1.31.0-E3344CC6C11D674C408FBF98D8EEFA551F60B915102F9E22FF0F316715677AD5/dub_test_root.d(3,15):
Expected 'oh/dear/dub/what/are/you/doing.d' or
'oh/dear/dub/what/are/you/doing/package.d' in one of the following import paths:
import path[0] = source/
import path[1] =
.dub/code/foo-test-library-unittest-linux.posix-x86_64-ldc_v1.31.0-E3344CC6C11D674C408FBF98D8EEFA551F60B915102F9E22FF0F316715677AD5
import path[2] = /opt/ldc/bin/../import
```
The DUB-generated test program:
```d
module dub_test_root;
import std.typetuple;
static import oh.dear.dub.what.are.you.doing;
// […]
```
Re: dub: standard project: how to build the unittest (the thing `dub test` runs)
On Saturday, 12 December 2020 at 12:47:59 UTC, Tobias Pankrath wrote: On Saturday, 12 December 2020 at 12:18:47 UTC, Andre Pany wrote: In any case you should have configurations in your dub json. Thank you for your detailed reply and I am sure I can make it work in the way you described. But I don't think my use case is invalid and dub should improve its usability here. Either it is indeed necessary to provide configuration even for very simple projects. Than dub should generate them on `dub init`. Or dub allows one to just build the test without running them. I'd propose `dub build test` or `dub build --test` for it. What do you think? As far as I remember someone else also requested the feature: building a test build without executing it. About the actual command I am not sure, maybe also `dub test --build` could be an option. Actually I add the configurations section to all dub projects, therefore I would like if dub init already add it by default. But I do not know whether this would be for other (new) users too confusing. Kind regards Andre
Re: dub: standard project: how to build the unittest (the thing `dub test` runs)
On Saturday, 12 December 2020 at 12:18:47 UTC, Andre Pany wrote: In any case you should have configurations in your dub json. Thank you for your detailed reply and I am sure I can make it work in the way you described. But I don't think my use case is invalid and dub should improve its usability here. Either it is indeed necessary to provide configuration even for very simple projects. Than dub should generate them on `dub init`. Or dub allows one to just build the test without running them. I'd propose `dub build test` or `dub build --test` for it. What do you think?
Re: dub: standard project: how to build the unittest (the thing `dub test` runs)
On Saturday, 12 December 2020 at 12:18:47 UTC, Andre Pany wrote: On Saturday, 12 December 2020 at 11:13:45 UTC, Tobias Pankrath wrote: [...] In any case you should have configurations in your dub json. For the first configuration, the name does not matter, it is used by default for command "dub" or "dub build", here you set targetType library. The second configuration you name unittest, you set targetType executable and you also have to set attribute mainSourceFile. This configuration is used automatically by command "dub test". Kind regards Andre Here is a more detailed example https://github.com/andre2007/coding-puzzles/blob/master/dub.json Kind regards Andre
Re: dub: standard project: how to build the unittest (the thing `dub test` runs)
On Saturday, 12 December 2020 at 11:13:45 UTC, Tobias Pankrath wrote: Whenever I come back to some D, I seem to be stumbling over dub. Somehow dub and I don't align: $ dub init dubtest && cd dubtest $ dub test -> creates executable `dubtest` (saying Falling back to "dub -b unittest".) $ touch source/lib.d dub test -> creates executable dubtest-test-library Question is: How do I build the `dubtest-test-library` without running the tests? If no explicit configuration is given, an existing "unittest" configuration will be preferred for testing. If none exists, the first library type configuration will be used, and if that doesn't exist either, the first executable configuration is chosen. I've tried $ dub test -b unittest -c library but that re-creates ./dubtest not ./dubtest-test-library. In any case you should have configurations in your dub json. For the first configuration, the name does not matter, it is used by default for command "dub" or "dub build", here you set targetType library. The second configuration you name unittest, you set targetType executable and you also have to set attribute mainSourceFile. This configuration is used automatically by command "dub test". Kind regards Andre
dub: standard project: how to build the unittest (the thing `dub test` runs)
Whenever I come back to some D, I seem to be stumbling over dub. Somehow dub and I don't align: $ dub init dubtest && cd dubtest $ dub test -> creates executable `dubtest` (saying Falling back to "dub -b unittest".) $ touch source/lib.d dub test -> creates executable dubtest-test-library Question is: How do I build the `dubtest-test-library` without running the tests? If no explicit configuration is given, an existing "unittest" configuration will be preferred for testing. If none exists, the first library type configuration will be used, and if that doesn't exist either, the first executable configuration is chosen. I've tried $ dub test -b unittest -c library but that re-creates ./dubtest not ./dubtest-test-library.
Re: Link error triggered by `dub test` but not by `dub build --unittest`
On Wednesday, 17 June 2020 at 12:12:24 UTC, Per Nordlöw wrote:
On Tuesday, 16 June 2020 at 12:21:26 UTC, Per Nordlöw wrote:
when
dub test
doesn't?
I'm trying to reduce it through
dustmite phobos-next "dub test 2>&1 | grep -F
'_D6object10_xopEqualsFMxPvMxQeZb'"
Is this the best way to use dustmite in this case?
Was reduced to rational.d with content
module nxt.rational;
Rational!(I1) rational(I1, I2)(I1 , I2)
{
return typeof(return)();
}
struct Rational(Int)
{
bool opEquals(Rhs)(Rhs _) {}
}
@nogc unittest
{
auto _ = rational(1, 2);
}
When I remove
bool opEquals(Rhs)(Rhs _) {}
error goes away. Seems like a bug to me.
Re: Link error triggered by `dub test` but not by `dub build --unittest`
On Tuesday, 16 June 2020 at 12:21:26 UTC, Per Nordlöw wrote: when dub test doesn't? I'm trying to reduce it through dustmite phobos-next "dub test 2>&1 | grep -F '_D6object10_xopEqualsFMxPvMxQeZb'" Is this the best way to use dustmite in this case?
Re: Link error triggered by `dub test` but not by `dub build --unittest`
On Tuesday, 16 June 2020 at 12:21:26 UTC, Per Nordlöw wrote: All the linker errors originate from zio.d but zio.d has its unittests disabled so how come this fails to link? zio.d is not the source of the problem. Something else is. The common denominator seems to be that the builtins xopEqual and xopCmp aren't defined upon linking. These seem to be generated by dmd. Can anybody explain what's going on here?
Link error triggered by `dub test` but not by `dub build --unittest`
Inside https://github.com/nordlow/phobos-next/ doing dub build --compiler=dmd --build=unittest works but dub test --compiler=dmd fails as Generating test runner configuration 'phobos-next-test-library' for 'library' (library). Performing "unittest" build using /usr/bin/dmd for x86_64. phobos-next ~master: building configuration "phobos-next-test-library"... Linking... .dub/build/phobos-next-test-library-unittest-linux.posix-x86_64-dmd_2092-4171FC1A47BBEE27E965310B42F6CCF0/phobos-next-test-library.o:src/nxt/zio.d:_D268TypeInfo_S4core8internal8lifetime__T10emplaceRefTS3nxt13dynamic_array__T12DynamicArrayTSQBm22sso_hashmap_or_hashset__T15SSOHashMapOrSetTkTCQDlQBz20__unittest_L1781_C15FNaNeZ1VVnnTSQFa7digestx3fnv__T3FNVVmi64Vbi1ZQoVki1Vki2Vki1ZQEf1TVQCfnTkZQGmTQHnTG2QGhZQIkFKQIcKQpZ1S6__initZ: error: undefined reference to '_D6object10_xopEqualsFMxPvMxQeZb' .dub/build/phobos-next-test-library-unittest-linux.posix-x86_64-dmd_2092-4171FC1A47BBEE27E965310B42F6CCF0/phobos-next-test-library.o:src/nxt/zio.d:_D270TypeInfo_S4core8internal8lifetime__T10emplaceRefTS3nxt13dynamic_array__T12DynamicArrayTSQBm22sso_hashmap_or_hashset__T15SSOHashMapOrSetTkTCQDlQBz20__unittest_L1837_C14FNaNbNfZ1VVnnTSQFc7digestx3fnv__T3FNVVmi64Vbi1ZQoVki1Vki2Vki1ZQEh1TVQCfnTkZQGoTQHpTG2QGjZQImFKQIeKQpZ1S6__initZ: error: undefined reference to '_D6object10_xopEqualsFMxPvMxQeZb' .dub/build/phobos-next-test-library-unittest-linux.posix-x86_64-dmd_2092-4171FC1A47BBEE27E965310B42F6CCF0/phobos-next-test-library.o:src/nxt/zio.d:_D124TypeInfo_S3std8typecons__T5TupleTSQy5range__T11SortedRangeTAiVAyaa5_61203c2062VEQCsQBv18SortedRangeOptionsi0ZQCmTQDcTQDgZQDr6__initZ: error: undefined reference to '_D6object7_xopCmpFMxPvMxQeZb' .dub/build/phobos-next-test-library-unittest-linux.posix-x86_64-dmd_2092-4171FC1A47BBEE27E965310B42F6CCF0/phobos-next-test-library.o:src/nxt/zio.d:_D109TypeInfo_S3std8typecons__T5TupleTiTS3nxt12algorithm_ex__T17forwardDifferenceTAiZQxFQgZ17ForwardDifferenceZQDc6__initZ: error: undefined reference to '_D6object7_xopCmpFMxPvMxQeZb' .dub/build/phobos-next-test-library-unittest-linux.posix-x86_64-dmd_2092-4171FC1A47BBEE27E965310B42F6CCF0/phobos-next-test-library.o:src/nxt/zio.d:_D49TypeInfo_S3std8typecons__T5TupleTC8TypeInfoTPvZQv6__initZ: error: undefined reference to '_D6object7_xopCmpFMxPvMxQeZb' .dub/build/phobos-next-test-library-unittest-linux.posix-x86_64-dmd_2092-4171FC1A47BBEE27E965310B42F6CCF0/phobos-next-test-library.o:src/nxt/zio.d:_D52TypeInfo_S3std8typecons__T5TupleTC8TypeInfoTPG32hZQy6__initZ: error: undefined reference to '_D6object7_xopCmpFMxPvMxQeZb' .dub/build/phobos-next-test-library-unittest-linux.posix-x86_64-dmd_2092-4171FC1A47BBEE27E965310B42F6CCF0/phobos-next-test-library.o:src/nxt/zio.d:_D3nxt5bound22BoundOverflowException6__vtblZ: error: undefined reference to '_D6object9Throwable8toStringMxFMDFMxAaZvZv' .dub/build/phobos-next-test-library-unittest-linux.posix-x86_64-dmd_2092-4171FC1A47BBEE27E965310B42F6CCF0/phobos-next-test-library.o:src/nxt/zio.d:_D3nxt6cyclic16CyclicRangeError6__vtblZ: error: undefined reference to '_D6object9Throwable8toStringMxFMDFMxAaZvZv' .dub/build/phobos-next-test-library-unittest-linux.posix-x86_64-dmd_2092-4171FC1A47BBEE27E965310B42F6CCF0/phobos-next-test-library.o:src/nxt/zio.d:_D46TypeInfo_S3nxt6cyclic__T11CyclicArrayTiVmi0ZQu6__initZ: error: undefined reference to '_D6object10_xopEqualsFMxPvMxQeZb' .dub/build/phobos-next-test-library-unittest-linux.posix-x86_64-dmd_2092-4171FC1A47BBEE27E965310B42F6CCF0/phobos-next-test-library.o:src/nxt/zio.d:_D70TypeInfo_S3nxt6cyclic__T11CyclicArrayTSQBdQBc13structBug5920Vmi256ZQBr6__initZ: error: undefined reference to '_D6object10_xopEqualsFMxPvMxQeZb' .dub/build/phobos-next-test-library-unittest-linux.posix-x86_64-dmd_2092-4171FC1A47BBEE27E965310B42F6CCF0/phobos-next-test-library.o:src/nxt/zio.d:_D3nxt7variant23LightAlgebraicException6__vtblZ: error: undefined reference to '_D6object9Throwable8toStringMxFMDFMxAaZvZv' collect2: error: ld returned 1 exit status Error: linker exited with status 1 /usr/bin/dmd failed with exit code 1. All the linker errors originate from zio.d but zio.d has its unittests disabled so how come this fails to link? And how come dub build --unittest passes when dub test doesn't? I'm sitting on Ubuntu 20.04 x64.
Re: A `dub test` problem...
On Thursday, 8 November 2018 at 15:01:04 UTC, duge wrote: WTF, why i got a this modal messagebox when i trying `dub test --build=unittest` ?? i just captured messagebox and using OCR, and that's it. here: core.exceptionAssertError@source\dub\internal\vibecompat\core\log.d(85): Enforcement failed (No error) 0x00594079 in _d_assert_msg Ox0056A55D in nothrow @safe void dub.intemal.vibecompatcore.logiogErrorRimmutable(chae.lo gError(immutable(char)g, lazy immutable(char)g) at CWUsersWvagrantVklonesVidubVisourceVeduhAVinternalWvibeco mpatwcorewlog.d(47) Ox00409C24 in int dub.commandline.runDubCommandLine(immutable(chaOgg) at CWUsersWvagrantVklonesVidubVisourceViduhAikommandline.d( 272) Ox0040256E in _Dmain at CWUsersWvagrantVklonesWdubVisourceWapp.d(15) Ox00592DDF in void rtdmain2._d_run_mainent, char*, extern (C) int function(chargr).runA110._lambdal 0 Ox00592D61 in void rtdmain2._d_run_mainent, char", extern (C) int function(chargg)").runAll0 Ox00592BFB in _d_run_main Ox0040894C in main at CV/UsersWvagrantVklonesVidubVisourceiVapp.d(7) Ox0060D535 in mainCRTStartup 0x77608484 in BaseThreadlnitThunk Ox77E13O5A in RtlValidSecurityDescriptor Ox77E1302A in RtlValidSecurityDescriptor ---- yah, `dub test --build=unittest` didn't work. a dub made a test file for library(eg. libname-test-library.exe), but couldn't executed it. WHY??? But it didnt have no problem, when i tried executing `libname-test-library.exe` directly. WHY??? i have no idea. oh, sorry... my mistake. the content was mix. here is my original article: WTF, why i got a this modal messagebox when i trying `dub test --build=unittest` ?? i just captured messagebox and using OCR, and that's it. here: core.exceptionAssertError@source\dub\internal\vibecompat\core\log.d(85): Enforcement failed (No error) 0x00594079 in _d_assert_msg Ox0056A55D in nothrow @safe void dub.intemal.vibecompatcore.logiogErrorRimmutable(chae.lo gError(immutable(char)g, lazy immutable(char)g) at CWUsersWvagrantVklonesVidubVisourceVeduhAVinternalWvibeco mpatwcorewlog.d(47) Ox00409C24 in int dub.commandline.runDubCommandLine(immutable(chaOgg) at CWUsersWvagrantVklonesVidubVisourceViduhAikommandline.d( 272) Ox0040256E in _Dmain at CWUsersWvagrantVklonesWdubVisourceWapp.d(15) Ox00592DDF in void rtdmain2._d_run_mainent, char*, extern (C) int function(chargr).runA110._lambdal 0 Ox00592D61 in void rtdmain2._d_run_mainent, char", extern (C) int function(chargg)").runAll0 Ox00592BFB in _d_run_main Ox0040894C in main at CV/UsersWvagrantVklonesVidubVisourceiVapp.d(7) Ox0060D535 in mainCRTStartup 0x77608484 in BaseThreadlnitThunk Ox77E13O5A in RtlValidSecurityDescriptor Ox77E1302A in RtlValidSecurityDescriptor ---- yah, `dub test --build=unittest` didn't work. the dub made a test file for library(eg. libname-test-library.exe) successfull but couldn't executed it. WHY??? one of thing funny, it was work clearly when i tried executing `libname-test-library.exe` directly. WHY??? i have no idea.
A `dub test` problem...
WTF, why i got a this modal messagebox when i trying `dub test --build=unittest` ?? i just captured messagebox and using OCR, and that's it. here: core.exceptionAssertError@source\dub\internal\vibecompat\core\log.d(85): Enforcement failed (No error) 0x00594079 in _d_assert_msg Ox0056A55D in nothrow @safe void dub.intemal.vibecompatcore.logiogErrorRimmutable(chae.lo gError(immutable(char)g, lazy immutable(char)g) at CWUsersWvagrantVklonesVidubVisourceVeduhAVinternalWvibeco mpatwcorewlog.d(47) Ox00409C24 in int dub.commandline.runDubCommandLine(immutable(chaOgg) at CWUsersWvagrantVklonesVidubVisourceViduhAikommandline.d( 272) Ox0040256E in _Dmain at CWUsersWvagrantVklonesWdubVisourceWapp.d(15) Ox00592DDF in void rtdmain2._d_run_mainent, char*, extern (C) int function(chargr).runA110._lambdal 0 Ox00592D61 in void rtdmain2._d_run_mainent, char", extern (C) int function(chargg)").runAll0 Ox00592BFB in _d_run_main Ox0040894C in main at CV/UsersWvagrantVklonesVidubVisourceiVapp.d(7) Ox0060D535 in mainCRTStartup 0x77608484 in BaseThreadlnitThunk Ox77E13O5A in RtlValidSecurityDescriptor Ox77E1302A in RtlValidSecurityDescriptor ---- yah, `dub test --build=unittest` didn't work. a dub made a test file for library(eg. libname-test-library.exe), but couldn't executed it. WHY??? But it didnt have no problem, when i tried executing `libname-test-library.exe` directly. WHY??? i have no idea.
Re: dub test
On Friday, 2 February 2018 at 09:00:38 UTC, carblue wrote: On Friday, 2 February 2018 at 07:23:54 UTC, Joel wrote: [snip] Import module base from file ... source/jmisc/base.d by: import jmisc.base; and recommended read: https://code.dlang.org/package-format?lang=json Thanks carblue. I had to add 'source' as well to get it working.
Re: dub test
On Friday, 2 February 2018 at 07:23:54 UTC, Joel wrote:
When I try 'dub test' I get errors like 'Source file
'/Users/joelchristensen/jpro/dpro2/JMiscLib/source/jmisc/base.d' not found in any import path.'
Here's the dub.json file I'm using:
```
{
"name": "timelog",
"targetType": "executable",
"description": "A Joel D program. A D Diary program.",
"copyright": "Copyright © 2018, joelcnz - note: I don't
understand this",
"authors": ["Joel Ezra Christensen"],
"DFLAGS": ["g"],
"sourcePaths" : ["source",
"../JTaskLib/source",
"../JMiscLib/source"
],
"dependencies": {
"dlangui": "~>0.9.56"
}
}
```
Add before e.g. "dependencies"
"importPaths" : ["../JTaskLib/source",
"../JMiscLib/source"
],
Import module base from file ... source/jmisc/base.d by: import
jmisc.base;
and recommended read:
https://code.dlang.org/package-format?lang=json
dub test
When I try 'dub test' I get errors like 'Source file
'/Users/joelchristensen/jpro/dpro2/JMiscLib/source/jmisc/base.d'
not found in any import path.'
Here's the dub.json file I'm using:
```
{
"name": "timelog",
"targetType": "executable",
"description": "A Joel D program. A D Diary program.",
"copyright": "Copyright © 2018, joelcnz - note: I don't
understand this",
"authors": ["Joel Ezra Christensen"],
"DFLAGS": ["g"],
"sourcePaths" : ["source",
"../JTaskLib/source",
"../JMiscLib/source"
],
"dependencies": {
"dlangui": "~>0.9.56"
}
}
```
How to pass --DRT-covopt to dub test?
Hi, I have some issues to find out how I can pass --DRT-covopt to dub test. I am pretty sure this should work, but dub doesn't like it: dub test --coverage -- --DRT-covopt "dstpath:./cov" ... Running .\cov-sample.exe dstpath:./cov ... Is there s.th. I miss? Kind regards André
Re: hijack dub test
On 2017-08-31 08:41, Nicholas Wilson wrote: My project is a library, but I also need to test it and unit tests won't cut it (external hardware). How do you set up the dub.json to build the library normally but when it is invoked with `dub test` it runs a separate configuration that also includes files in the `source/test` folder, but are excluded when not testing. "The configuration name "unittest" has a special meaning - if a configuration with this name is present, it will be used by default when executing dub test." [1] [1] http://code.dlang.org/package-format?lang=json#configurations -- /Jacob Carlborg
hijack dub test
My project is a library, but I also need to test it and unit tests won't cut it (external hardware). How do you set up the dub.json to build the library normally but when it is invoked with `dub test` it runs a separate configuration that also includes files in the `source/test` folder, but are excluded when not testing. If thats not possible how does one specify that `source/test` should not be built when building a library and only `source/test` should be built when doing tests, but the tester depend in the library? Thanks Nic
Re: Does "dub test" run tests?
On 2017-03-20 10:07, Russel Winder via Digitalmars-d-learn wrote: And different behaviour with different build options, at least when using dmd, but I think the same is true for ldc2: |> dub test No source files found in configuration 'library'. Falling back to "dub -b unittest". Performing "unittest" build using dmd for x86_64. approxgc ~master: building configuration "application"... Linking... /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/Scrt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status Error: linker exited with status 1 dmd failed with exit code 1. 600 anglides:~/Repositories/Git/Masters/ApproxGC_D For me it works with "dub test" using DMD. But Dub does not seem to include its own "main" for running the tests. These are the interesting flags that Dub uses when invoking DMD when "dub test --verbose" is run: -debug -g -unittest -w -- /Jacob Carlborg
Re: Does "dub test" run tests?
On Mon, 2017-03-20 at 08:39 +, Russel Winder wrote: > […] > Actually it seems worse than that. Even with "dub -b unittest" it > appears that Dub compiles main.d without the -unittest flag to ldc2 > and so the normal application runs. And different behaviour with different build options, at least when using dmd, but I think the same is true for ldc2: |> dub test No source files found in configuration 'library'. Falling back to "dub -b unittest". Performing "unittest" build using dmd for x86_64. approxgc ~master: building configuration "application"... Linking... /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/Scrt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status Error: linker exited with status 1 dmd failed with exit code 1. 600 anglides:~/Repositories/Git/Masters/ApproxGC_D |> dub test --build=release No source files found in configuration 'library'. Falling back to "dub -b unittest". Performing "release" build using dmd for x86_64. approxgc ~master: building configuration "application"... Linking... Running ./approxgc ["b":["b_1.2.1.txt", "b_1.0.0.txt", "b_1.0.2.txt"], "a":["a_1.1.0.txt", "a_1.0.1.txt", "a_1.0.0.txt"]] ["b_1.0.0.txt", "b_1.0.2.txt", "a_1.0.0.txt", "a_1.0.1.txt"] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Does "dub test" run tests?
On Mon, 2017-03-20 at 00:58 -0700, Jonathan M Davis via Digitalmars-d- learn wrote: > […] > I haven't spent the time to dig in and report it properly, but based > on some > of what I saw recently on a project I have, the module with main in > it > didn't have its tests run, as if dub's didn't compile it when > compiling the > unit tests. The tests in the other modules were definitely run > though. So, I > think that dub probably does have a bug with regards to how it > handles the > module with main in it. Actually it seems worse than that. Even with "dub -b unittest" it appears that Dub compiles main.d without the -unittest flag to ldc2 and so the normal application runs. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Does "dub test" run tests?
On Monday, March 20, 2017 07:51:09 Russel Winder via Digitalmars-d-learn
wrote:
> I have a Meson build for a D program project with a single main.d file
> that has some unit tests. Both executable and test executable are
> created and work as expected.
>
> I created a minimal Dub file for this project. Using Dub the program
> runs as expected. However when I run "dub test" it claims to be running
> "dub -b unittest" and then proceeds to run the program not the tests.
>
> In main.d I have:
>
> ... some most excellent D code …
>
> version(unittest) {
> ... the unit tests ...
> }
> else {
> ... the application main ...
> }
>
> so whilst the Meson/Ninja "ldc2 -unittest --main" thing works fine, Dub
> doesn't do the right thing. Or more likely I am just missing something
> obvious.
I haven't spent the time to dig in and report it properly, but based on some
of what I saw recently on a project I have, the module with main in it
didn't have its tests run, as if dub's didn't compile it when compiling the
unit tests. The tests in the other modules were definitely run though. So, I
think that dub probably does have a bug with regards to how it handles the
module with main in it.
- Jonathan M Davis
Does "dub test" run tests?
I have a Meson build for a D program project with a single main.d file
that has some unit tests. Both executable and test executable are
created and work as expected.
I created a minimal Dub file for this project. Using Dub the program
runs as expected. However when I run "dub test" it claims to be running
"dub -b unittest" and then proceeds to run the program not the tests.
In main.d I have:
... some most excellent D code …
version(unittest) {
... the unit tests ...
}
else {
... the application main ...
}
so whilst the Meson/Ninja "ldc2 -unittest --main" thing works fine, Dub
doesn't do the right thing. Or more likely I am just missing something
obvious.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Is there a way to disable 'dub test' for applications?
On Monday, 18 April 2016 at 18:19:32 UTC, Jon D wrote:
On Monday, 18 April 2016 at 11:47:42 UTC, Dicebot wrote:
On Monday, 18 April 2016 at 04:25:25 UTC, Jon D wrote:
I have an dub config file specifying a targetType of
'executable'. There is only one file, the file containing
main(), and no unit tests.
When I run 'dub test', dub builds and runs the executable.
This is not really desirable. Is there a way to set up the
dub configuration file to disable running the test?
configuration "unittest" {
excludedSourceFiles "path/to/main.d"
}
Very nice, thank you. What also seems to work is:
configuration "unittest" {
targetType "none"
}
Then 'dub test' produces the message:
Configuration 'unittest' has target type "none". Skipping
test.
Those two option do different things. My proposal excludes file
with `main` function from tested sources but keeps actual test
target (so if you have unittest blocks in other modules, those
will be checked). Your version completely disabled test target.
I wasn't sure which option you want but glad it helped.
Re: Is there a way to disable 'dub test' for applications?
On Monday, 18 April 2016 at 11:47:42 UTC, Dicebot wrote:
On Monday, 18 April 2016 at 04:25:25 UTC, Jon D wrote:
I have an dub config file specifying a targetType of
'executable'. There is only one file, the file containing
main(), and no unit tests.
When I run 'dub test', dub builds and runs the executable.
This is not really desirable. Is there a way to set up the dub
configuration file to disable running the test?
configuration "unittest" {
excludedSourceFiles "path/to/main.d"
}
Very nice, thank you. What also seems to work is:
configuration "unittest" {
targetType "none"
}
Then 'dub test' produces the message:
Configuration 'unittest' has target type "none". Skipping
test.
Re: Is there a way to disable 'dub test' for applications?
On Monday, 18 April 2016 at 04:25:25 UTC, Jon D wrote:
I have an dub config file specifying a targetType of
'executable'. There is only one file, the file containing
main(), and no unit tests.
When I run 'dub test', dub builds and runs the executable. This
is not really desirable. Is there a way to set up the dub
configuration file to disable running the test?
configuration "unittest" {
excludedSourceFiles "path/to/main.d"
}
Re: Is there a way to disable 'dub test' for applications?
You can write it in code: version(unittest) static assert(false,"unit tests not supported");
Re: Is there a way to disable 'dub test' for applications?
On Monday, 18 April 2016 at 05:30:21 UTC, Jonathan M Davis wrote: On Monday, April 18, 2016 04:25:25 Jon D via Digitalmars-d-learn wrote: I have an dub config file specifying a targetType of 'executable'. There is only one file, the file containing main(), and no unit tests. When I run 'dub test', dub builds and runs the executable. This is not really desirable. Is there a way to set up the dub configuration file to disable running the test? Note: What I'd really like to do is run a custom shell command when 'dub test' is done, I haven't seen anything suggesting that's an option. However, disabling would still be useful. What's the point of even running dub test if you have no unit tests? Just do dub build, and then use the resulting executable, or if you want to build and run in one command, then use dub run. - Jonathan M Davis I should have supplied more context. A few days ago I announced open-sourcing a D package consisting of several executables. Multiple comments recommended making it available via the Dub repository. I wasn't using Dub to build, and there are a number of loose ends when working with Dub and multiple executables. I've been trying to limit the number of issues others might encounter if they pulled the package and ran typical commands, like 'dub test'. It's not a big deal, but if there's an easy way to provide a handler, I will. Also, the reason for a custom shell command is that there are tests, it's just that they are run against the built executable rather than via the unittest framework. --Jon
Re: Is there a way to disable 'dub test' for applications?
On Monday, April 18, 2016 04:25:25 Jon D via Digitalmars-d-learn wrote: > I have an dub config file specifying a targetType of > 'executable'. There is only one file, the file containing main(), > and no unit tests. > > When I run 'dub test', dub builds and runs the executable. This > is not really desirable. Is there a way to set up the dub > configuration file to disable running the test? > > Note: What I'd really like to do is run a custom shell command > when 'dub test' is done, I haven't seen anything suggesting > that's an option. However, disabling would still be useful. What's the point of even running dub test if you have no unit tests? Just do dub build, and then use the resulting executable, or if you want to build and run in one command, then use dub run. - Jonathan M Davis
Is there a way to disable 'dub test' for applications?
I have an dub config file specifying a targetType of 'executable'. There is only one file, the file containing main(), and no unit tests. When I run 'dub test', dub builds and runs the executable. This is not really desirable. Is there a way to set up the dub configuration file to disable running the test? Note: What I'd really like to do is run a custom shell command when 'dub test' is done, I haven't seen anything suggesting that's an option. However, disabling would still be useful. --Jon
