There are points when you need to ask someone for help…

I am trying to get Dub to build integration tests from test-source as a separate thing from building unit tests from source. The latter is easy and works, as does building the application. I cannot however get the integration tests to build, I always get something along the lines of:

../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(10,12): Error: function D main conflicts with static import dub_test_root.main at ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(3,15)

and I haven't a clue. This is almost certainly just a bad dub.sdl file, but, if anyone can take a look at tell me what I am failing to get right, I'd appreciate it.

https://github.com/russel/ApproxGC


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

16.04.2017 11:20, Russel Winder via Digitalmars-d-learn пишет:
> There are points when you need to ask someone for help…
>
> I am trying to get Dub to build integration tests from test-source as a
> separate thing from building unit tests from source. The latter is easy
> and works, as does building the application. I cannot however get the
> integration tests to build, I always get something along the lines of:
>
> ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(10,12): Error: function D main conflicts with static import dub_test_root.main at ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(3,15)
>
> and I haven't a clue. This is almost certainly just a bad dub.sdl file,
> but, if anyone can take a look at tell me what I am failing to get
> right, I'd appreciate it.
>
> https://github.com/russel/ApproxGC
>
>
Try to add version for `integrationtest` to exclude `main` from building like you did with unittests version. In dub.sdl add versions "integrationtests" for correspondence configuration and in `source\main.d` add something like that:
```
...
unittest {
		 auto item = getValue!(Tuple!(string, string));
		 assert(debianPackageNumberLessThan(item[0], item[1]), format("[%s, %s]", item[0], item[1]));
	 }

}
else version(integrationtests){
	// do something here
}
else {
	int main(string[] args) {
...
```
It works for me. But frankly I failed to reproduce your error - I have other one like
```
ut_main.d(5,5): Error: only one main allowed. Previously found main at source/main.d(161,6)
dmd failed with exit code 1.
```
so very probably I fix wrong problem

On Sun, 2017-04-16 at 12:04 +0300, drug via Digitalmars-d-learn wrote:
> 
[…]
> Try to add version for `integrationtest` to exclude `main` from
> building
> like you did with unittests version. In dub.sdl add versions
> "integrationtests" for correspondence configuration and in
> `source\main.d` add something like that:

I believe that dub test will set unittest, that integrationtests is not
set as a version symbol. Indeed experiments with ldc2 seem to indicate
that "else version(…)" doesn't seem to work.

> ```
> ...
> unittest {
> 		 auto item = getValue!(Tuple!(string, string));
> 		 assert(debianPackageNumberLessThan(item[0], item[1]),
> format("[%s,
> %s]", item[0], item[1]));
> 	 }
> 
> }
> else version(integrationtests){
> 	// do something here
> }
> else {
> 	int main(string[] args) {
> ...
> ```
> It works for me. But frankly I failed to reproduce your error - I
> have
> other one like
> ```
> ut_main.d(5,5): Error: only one main allowed. Previously found main
> at
> source/main.d(161,6)
> dmd failed with exit code 1.
> ```
> so very probably I fix wrong problem

Are you on a different platform/compiler combination and so just getting different views on the same problem. I am on Fedora Rawhide with ldc2 from packaging. D 2.071 I think.

I'll try Debian where I have dmd (oh that doesn't work for other
reasons as yet uninvestigated), ldc2 (same version as Fedora I believe,
so should not be different), and gdc (but I think I am using D features
not supported yet there, but I will check).

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 2017-04-16 10:20, Russel Winder via Digitalmars-d-learn wrote:
> There are points when you need to ask someone for help…
>
> I am trying to get Dub to build integration tests from test-source as a
> separate thing from building unit tests from source. The latter is easy
> and works, as does building the application. I cannot however get the
> integration tests to build, I always get something along the lines of:
>
> ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(10,12): Error: function D main conflicts with static import dub_test_root.main at ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(3,15)
>
> and I haven't a clue. This is almost certainly just a bad dub.sdl file,
> but, if anyone can take a look at tell me what I am failing to get
> right, I'd appreciate it.
>
> https://github.com/russel/ApproxGC

I cannot build the tests at all:

unit_threaded/runtime.d(47,8): Error: module std.file import 'dirName' not found

This [1] is what I've done for one of my projects to have the tests in a separate directory. But I don't have any unit tests among the regular source files. The difference I can see is what you've specified for "sourceFiles". Perhaps remove "source/main.d"?

[1] https://github.com/jacob-carlborg/kiwi/blob/dev/dub.sdl#L11-L22

-- 
/Jacob Carlborg

On Mon, 2017-04-17 at 11:03 +0200, Jacob Carlborg via Digitalmars-d- learn wrote:

Thanks for the pointers to the example, I shall peruse.

I now have the SCons build working fine (OK so there are bugs in the
application code highlighted by the integration test bugs), so the D
code is not wrong. The fact I cannot get a Dub build is clearly to do
with my dub.sdl (most likely), or Dub is doing something wrong (highly
unlikely I would guess, but…)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sunday, 16 April 2017 at 08:20:21 UTC, Russel Winder wrote:
> There are points when you need to ask someone for help…
>
> I am trying to get Dub to build integration tests from test-source as a separate thing from building unit tests from source. The latter is easy and works, as does building the application. I cannot however get the integration tests to build, I always get something along the lines of:
>
> ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(10,12): Error: function D main conflicts with static import dub_test_root.main at ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(3,15)
>
> and I haven't a clue. This is almost certainly just a bad dub.sdl file, but, if anyone can take a look at tell me what I am failing to get right, I'd appreciate it.
>
> https://github.com/russel/ApproxGC

https://github.com/russel/ApproxGC/pull/2

Unfortunately the auto generated integration test main file doesn't quite work (feel free to file a bug on unit-threaded) so in that PR I disabled auto-generating it and force added my edited version.

What I did there in dub.sdl is my current go-to solution for also running integration tests with unit-threaded.

Atila

On Mon, 2017-04-17 at 22:56 +0000, Atila Neves via Digitalmars-d-learn wrote:
> 
[…]
> https://github.com/russel/ApproxGC/pull/2
> 
> Unfortunately the auto generated integration test main file doesn't quite work (feel free to file a bug on unit-threaded) so in that PR I disabled auto-generating it and force added my edited version.
> 
> What I did there in dub.sdl is my current go-to solution for also running integration tests with unit-threaded.
> 

Thanks for that, much appreciated. I am hesitant to commit the pull request for now in case get_ut_main gets fixed fairly quickly. For the moment I am progressing with the SCons build since I got it working.

As per your advice I wrote a SCons specific Python function to do the same as get_ut_main – and it works, well for my very restricted test cases anyway. I think my Python code only solves a part of the problem your get_ut_main solves: I think I need to extend the Python function to cover more cases. I'll do it on an as needed, only with a test case, basis though.

The real joy is that I have Unit-Threaded working. It's extensions of the unittest D language feature make testing D codes far more fun than the basic feature. Thanks for putting in the effort.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 18 April 2017 at 07:07:16 UTC, Russel Winder wrote:
> On Mon, 2017-04-17 at 22:56 +0000, Atila Neves via Digitalmars-d-learn wrote:
>> 
> […]
>> https://github.com/russel/ApproxGC/pull/2
>> 
>> Unfortunately the auto generated integration test main file doesn't quite work (feel free to file a bug on unit-threaded) so in that PR I disabled auto-generating it and force added my edited version.
>> 
>> What I did there in dub.sdl is my current go-to solution for also running integration tests with unit-threaded.
>> 
>
> Thanks for that, much appreciated. I am hesitant to commit the pull request for now in case get_ut_main gets fixed fairly quickly. For the moment I am progressing with the SCons build since I got it working.

I wouldn't hold my breath - the fix is annoying and non-trivial. Basically I special cased "source" since it's the default for dub packages but "test-source" gums up the works and I'd have to look at it properly.

> The real joy is that I have Unit-Threaded working. It's extensions of the unittest D language feature make testing D codes far more fun than the basic feature. Thanks for putting in the effort.

I'm happy the work is appreciated :)

Atila