Jump to page: 1 2
Thread overview
dub test
Aug 23, 2016
Jacob Carlborg
Aug 23, 2016
Jacob Carlborg
Aug 23, 2016
John Colvin
Aug 23, 2016
Seb
Aug 24, 2016
Edwin van Leeuwen
Aug 24, 2016
Jacob Carlborg
Aug 24, 2016
Edwin van Leeuwen
Aug 24, 2016
Seb
Sep 01, 2016
Lurker
Aug 24, 2016
H. S. Teoh
Aug 30, 2016
Atila Neves
August 23, 2016
Why does "dub test" rebuild the library? It should just re-run unittests. -- Andrei
August 23, 2016
On 2016-08-23 19:55, Andrei Alexandrescu wrote:
> Why does "dub test" rebuild the library? It should just re-run
> unittests. -- Andrei

Rebuilds it with unit tests enabled? You can the "--verbose" and/or the "--vverbose" to see exactly the commands that Dub are running.

-- 
/Jacob Carlborg
August 23, 2016
On 08/23/2016 03:14 PM, Jacob Carlborg wrote:
> On 2016-08-23 19:55, Andrei Alexandrescu wrote:
>> Why does "dub test" rebuild the library? It should just re-run
>> unittests. -- Andrei
>
> Rebuilds it with unit tests enabled? You can the "--verbose" and/or the
> "--vverbose" to see exactly the commands that Dub are running.

It does this with every run per --verbose (it should not rebuild the test program):

Using dub registry url 'http://code.dlang.org/'
Refreshing local packages (refresh existing: true)...
Looking for local package map at /var/lib/dub/packages/local-packages.json
Looking for local package map at /home/andrei/.dub/packages/local-packages.json
Determined package version using GIT: checkedint_andralex 0.0.2
Refreshing local packages (refresh existing: false)...
Looking for local package map at /var/lib/dub/packages/local-packages.json
Looking for local package map at /home/andrei/.dub/packages/local-packages.json
Checking for missing dependencies.
Refreshing local packages (refresh existing: false)...
Looking for local package map at /var/lib/dub/packages/local-packages.json
Looking for local package map at /home/andrei/.dub/packages/local-packages.json
Checking for upgrades.
Using cached upgrade results...
Generating test runner configuration '__test__library__' for 'library' (library).
Get module name from path: /home/andrei/d/dub/checkedint_andralex/source/checkedint.d
Refreshing local packages (refresh existing: false)...
Looking for local package map at /var/lib/dub/packages/local-packages.json
Looking for local package map at /home/andrei/.dub/packages/local-packages.json
Generate target checkedint_andralex (executable /home/andrei/d/dub/checkedint_andralex __test__library__)
Performing "unittest" build using dmd for x86_64.
File '../../../../../tmp/dub_test_root-8422d71d-ca6f-4781-9307-b7ff54bb0b8f.d' modified, need rebuild.
checkedint_andralex 0.0.2: building configuration "__test__library__"...
dmd -c -of.dub/build/__test__library__-unittest-linux.posix-x86_64-dmd_2072-0DDE52948EB4C282B88B8F001B09B726/__test__library__.o -debug -g -unittest -w -version=VibeCustomMain -version=Have_checkedint_andralex -Isource/ ../../../../../tmp/dub_test_root-8422d71d-ca6f-4781-9307-b7ff54bb0b8f.d source/checkedint.d -vcolumns
Linking...
dmd -of.dub/build/__test__library__-unittest-linux.posix-x86_64-dmd_2072-0DDE52948EB4C282B88B8F001B09B726/__test__library__ .dub/build/__test__library__-unittest-linux.posix-x86_64-dmd_2072-0DDE52948EB4C282B88B8F001B09B726/__test__library__.o -L--no-as-needed -g
Copying target from /home/andrei/d/dub/checkedint_andralex/.dub/build/__test__library__-unittest-linux.posix-x86_64-dmd_2072-0DDE52948EB4C282B88B8F001B09B726/__test__library__ to /home/andrei/d/dub/checkedint_andralex
Running ./__test__library__
All unit tests have been run successfully.



Andrei


August 23, 2016
On 2016-08-23 21:26, Andrei Alexandrescu wrote:
> On 08/23/2016 03:14 PM, Jacob Carlborg wrote:
>> On 2016-08-23 19:55, Andrei Alexandrescu wrote:
>>> Why does "dub test" rebuild the library? It should just re-run
>>> unittests. -- Andrei
>>
>> Rebuilds it with unit tests enabled? You can the "--verbose" and/or the
>> "--vverbose" to see exactly the commands that Dub are running.
>
> It does this with every run per --verbose (it should not rebuild the
> test program):

You mean this line?

dmd -c -of.dub/build/__test__library__ ...

That's builds a generated module which imports all modules in the project. It looks like this is a temporary file that is removed after each run.

As Walter would say, if it's not in bugzilla it will never be fixed ;)

-- 
/Jacob Carlborg
August 23, 2016
On 08/23/2016 04:06 PM, Jacob Carlborg wrote:
> On 2016-08-23 21:26, Andrei Alexandrescu wrote:
>> On 08/23/2016 03:14 PM, Jacob Carlborg wrote:
>>> On 2016-08-23 19:55, Andrei Alexandrescu wrote:
>>>> Why does "dub test" rebuild the library? It should just re-run
>>>> unittests. -- Andrei
>>>
>>> Rebuilds it with unit tests enabled? You can the "--verbose" and/or the
>>> "--vverbose" to see exactly the commands that Dub are running.
>>
>> It does this with every run per --verbose (it should not rebuild the
>> test program):
>
> You mean this line?
>
> dmd -c -of.dub/build/__test__library__ ...
>
> That's builds a generated module which imports all modules in the
> project. It looks like this is a temporary file that is removed after
> each run.
>
> As Walter would say, if it's not in bugzilla it will never be fixed ;)

https://issues.dlang.org/show_bug.cgi?id=16422 -- Andrei

August 23, 2016
On Tuesday, 23 August 2016 at 20:26:12 UTC, Andrei Alexandrescu wrote:
>> As Walter would say, if it's not in bugzilla it will never be fixed ;)
>
> https://issues.dlang.org/show_bug.cgi?id=16422 -- Andrei

https://github.com/dlang/dub/issues is full of existing issues, not sure whether it's best to split reports between there and issues.dlang.org
August 23, 2016
On Tuesday, 23 August 2016 at 21:51:57 UTC, John Colvin wrote:
> On Tuesday, 23 August 2016 at 20:26:12 UTC, Andrei Alexandrescu wrote:
>>> As Walter would say, if it's not in bugzilla it will never be fixed ;)
>>
>> https://issues.dlang.org/show_bug.cgi?id=16422 -- Andrei
>
> https://github.com/dlang/dub/issues is full of existing issues, not sure whether it's best to split reports between there and issues.dlang.org

Yep, Sönke is highly overloaded with the amount of issues popping in.

Reminder: he also maintains our flagship web framework vibe.d, ddox, a proposal for std.data.json, the dub-registry itself, a couple of other projects and his full-time job. We really need more manpower behind DUB!
August 24, 2016
On Tuesday, 23 August 2016 at 17:55:41 UTC, Andrei Alexandrescu wrote:
> Why does "dub test" rebuild the library? It should just re-run unittests. -- Andrei

To be honest I prefer it to rebuild it. Why would you want to rerun the tests without a rebuild? It should give the same failure/success as last time.
August 24, 2016
On 2016-08-24 07:44, Edwin van Leeuwen wrote:

> To be honest I prefer it to rebuild it. Why would you want to rerun the
> tests without a rebuild? It should give the same failure/success as last
> time.

Sure, but one might not figure why a test is failing after only a single run. One might use "dub test" to run integration tests that depends on some external dependency that is causing the test to fail. There are many reasons to run the test without recompiling.

What is the point of recompiling when nothing has changed?

-- 
/Jacob Carlborg
August 24, 2016
On Wednesday, 24 August 2016 at 06:32:54 UTC, Jacob Carlborg wrote:
> Sure, but one might not figure why a test is failing after only a single run. One might use "dub test" to run integration tests that depends on some external dependency that is causing the test to fail.

I always considered dub test to be only for running unittests and not really suited for integration tests, but if that is a use case then fair enough.

> There are many reasons to run the test without recompiling.

I might be dense, but the only other thing than integration tests that I can think of is if you use random data for testing, but that would be more correctly solved by using more random data during the unittests. Nothing is worse than tests that only sometimes fail.

> What is the point of recompiling when nothing has changed?

I'd be all for for dub to analyse whether there are any changes, but AFAIK dub's focus is as a packaging system, not as a build system. In that case I'd prefer it to ere on the side of caution and recompile more often in case there might be a change. Maybe the key would be to replace dub's limited build system by an external build system such as reggea.
« First   ‹ Prev
1 2