www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Empty LST files?

reply Thalamus <norobots foo.com> writes:
I'm running into a problem where when I specify -cov in the DMD 
compiler command, the coverage LST files are generated, but 
they're all empty. Has anyone else run into this before? My 
command line is:

dmd -m64 -gc -debug -w -wi -cov -X -Xf"obj\Unit.json" -I\ 
-deps="obj\Unit.dep" -c -odobj\Unit.build.rsp Interfaces.obj 
Invokers.obj (plus a whole lot of other .objs)

This is for a test EXE. I thought there may be some trouble when 
generating files for the .d from the .obj files, but even the .d 
files local to the test EXE end up with empty LST files.

Any idea what I'm doing wrong?

thanks!
Jul 30 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 31 July 2016 at 01:10:40 UTC, Thalamus wrote:

 I'm running into a problem where when I specify -cov in the DMD 
 compiler command, the coverage LST files are generated, but 
 they're all empty. Has anyone else run into this before? My 
 command line is:

 dmd -m64 -gc -debug -w -wi -cov -X -Xf"obj\Unit.json" -I\ 
 -deps="obj\Unit.dep" -c -odobj\Unit.build.rsp Interfaces.obj 
 Invokers.obj (plus a whole lot of other .objs)

 This is for a test EXE. I thought there may be some trouble 
 when generating files for the .d from the .obj files, but even 
 the .d files local to the test EXE end up with empty LST files.

 Any idea what I'm doing wrong?


Yes, what's going wrong is quite obvious. Coverage files are 
generated at run-time by the target application and not by the 
compiler at compile-time.

In your options I can see that you generate an object file. You 
should rather compile for running the unittests: e.g:

     -main -unittest -cov

and then execute the target application to generate the LST.
Jul 31 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 31 July 2016 at 08:29:47 UTC, Basile B. wrote:

 On Sunday, 31 July 2016 at 01:10:40 UTC, Thalamus wrote:

 Any idea what I'm doing wrong?


 Yes, what's going wrong is quite


actually you said that the LST is well generated but empty so my 
previous answer is  wrong, also i was focused on unittest 
coverage which doesn't seem to be what you want to verify.
Jul 31 2016
parent reply Thalamus <norobots foo.com> writes:
On Sunday, 31 July 2016 at 10:05:04 UTC, Basile B. wrote:

 On Sunday, 31 July 2016 at 08:29:47 UTC, Basile B. wrote:

 On Sunday, 31 July 2016 at 01:10:40 UTC, Thalamus wrote:

 Any idea what I'm doing wrong?


 Yes, what's going wrong is quite


 actually you said that the LST is well generated but empty so 
 my previous answer is  wrong, also i was focused on unittest 
 coverage which doesn't seem to be what you want to verify.


Thank Basile. Yes, these aren't unit tests, but rather 
integration tests, end-to-end tests, etc., all of which are 
driven from external EXEs. This is a complex application 

project, D (and Visual D) work very well, but across projects 
I've run into a lot of challenges. Not being able to build these 
projects into DLLs without resorting to C-linkage for D-to-D 
interop (which Benjamin Thaut is working on fixing) was tough to 
swallow, and I can't used LIBs because in some cases I have 
projects that are not referenced at build time but whose classes 
are instead discovered at run time, so I'm forced to resort to 
OBJs for now. Code coverage is a must, though, so I'm really 
digging in here.

I found part of the problem: Hitting F5 in Visual Studio after a 
fresh rebuild was giving me an error "cannot launch debugger... 
hr = 89710016" which looks to be related to Visual D. Subsequent 
runs work fine, but it was annoying me so I added the EXE itself 
as the startup project. This ran properly every time, but it 
resulted the LST files ending up in the build folder, and they 
were all empty. So I switched back to the test project as the 
startup project and, after the errant run, it generated LSTs in 
the EXE project root folder as expected. In this case, all the 
test EXE LST files were populated as expected, but all of the 
LSTs for the code being tested were still empty. I really don't 
need code coverage numbers for the test code, and currently I 
still get none for the code I do need to measure. But it's still 
progress.

If anyone else has ideas I'd love to hear them. Otherwise, if I 
figure it out, I will add a quick explanation to this thread.

thanks!
Jul 31 2016
parent reply Thalamus <norobots foo.com> writes:
On Sunday, 31 July 2016 at 14:03:49 UTC, Thalamus wrote:

 On Sunday, 31 July 2016 at 10:05:04 UTC, Basile B. wrote:

 On Sunday, 31 July 2016 at 08:29:47 UTC, Basile B. wrote:

 On Sunday, 31 July 2016 at 01:10:40 UTC, Thalamus wrote:

 Any idea what I'm doing wrong?


 Yes, what's going wrong is quite


 actually you said that the LST is well generated but empty so 
 my previous answer is  wrong, also i was focused on unittest 
 coverage which doesn't seem to be what you want to verify.


 Thank Basile. Yes, these aren't unit tests, but rather 
 integration tests, end-to-end tests, etc., all of which are 
 driven from external EXEs. This is a complex application 

 project, D (and Visual D) work very well, but across projects 
 I've run into a lot of challenges. Not being able to build 
 these projects into DLLs without resorting to C-linkage for 
 D-to-D interop (which Benjamin Thaut is working on fixing) was 
 tough to swallow, and I can't used LIBs because in some cases I 
 have projects that are not referenced at build time but whose 
 classes are instead discovered at run time, so I'm forced to 
 resort to OBJs for now. Code coverage is a must, though, so I'm 
 really digging in here.

 I found part of the problem: Hitting F5 in Visual Studio after 
 a fresh rebuild was giving me an error "cannot launch 
 debugger... hr = 89710016" which looks to be related to Visual 
 D. Subsequent runs work fine, but it was annoying me so I added 
 the EXE itself as the startup project. This ran properly every 
 time, but it resulted the LST files ending up in the build 
 folder, and they were all empty. So I switched back to the test 
 project as the startup project and, after the errant run, it 
 generated LSTs in the EXE project root folder as expected. In 
 this case, all the test EXE LST files were populated as 
 expected, but all of the LSTs for the code being tested were 
 still empty. I really don't need code coverage numbers for the 
 test code, and currently I still get none for the code I do 
 need to measure. But it's still progress.

 If anyone else has ideas I'd love to hear them. Otherwise, if I 
 figure it out, I will add a quick explanation to this thread.

 thanks!


After a couple more hours today, I found a couple of solutions. 
Neither is satisfactory.

The first is to include the project that builds the EXE in the 
same folder as the project that builds the OBJ. The problem with 
this is that each OBJ will also have to have its own EXE, and 
aggregating information from each of these EXEs becomes a real 
chore.

The second is to include all the source files directly in the 
test EXE project, AND to move the test EXE into its own solution. 
Having to maintain the same module hierarchy in two projects is 
obviously error prone. Having to maintain the separate solution 
is not a problem, really, but the reason it's necessary is a bit 
annoying: it seems that Visual D automatically includes the OBJ 
for any project previously built in the build process of 
subsequent projects, so whether you build the test EXE first or 
last, you end up with multiple definition problems, once in the 
EXE and once in the project OBJ, or once in the project and once 
in the EXE's OBJ. Either way the build breaks.

If anyone has a third alternative, please let me know! Otherwise, 
I'll have to select the lesser of these two evils.

thanks!
Jul 31 2016
parent reply Seb <seb wilzba.ch> writes:
On Sunday, 31 July 2016 at 15:30:46 UTC, Thalamus wrote:

 On Sunday, 31 July 2016 at 14:03:49 UTC, Thalamus wrote:

 [...]


 After a couple more hours today, I found a couple of solutions. 
 Neither is satisfactory.

 [...]


How about setting the source path directly? With a recent enough 
dmd version this can be done automatically like here:
https://github.com/dlang/dmd/pull/5990/files
Jul 31 2016
parent reply Thalamus <norobots foo.com> writes:
On Sunday, 31 July 2016 at 16:08:49 UTC, Seb wrote:

 On Sunday, 31 July 2016 at 15:30:46 UTC, Thalamus wrote:

 On Sunday, 31 July 2016 at 14:03:49 UTC, Thalamus wrote:

 [...]


 After a couple more hours today, I found a couple of 
 solutions. Neither is satisfactory.

 [...]


 How about setting the source path directly? With a recent 
 enough dmd version this can be done automatically like here:
 https://github.com/dlang/dmd/pull/5990/files


Thanks Seb. Has this been included in an official version release 
yet? (I'm not sure how to tell. I've only used Git a small 
amount.)

thanks!
Jul 31 2016
parent reply Seb <seb wilzba.ch> writes:
On Sunday, 31 July 2016 at 16:48:52 UTC, Thalamus wrote:

 On Sunday, 31 July 2016 at 16:08:49 UTC, Seb wrote:

 On Sunday, 31 July 2016 at 15:30:46 UTC, Thalamus wrote:

 On Sunday, 31 July 2016 at 14:03:49 UTC, Thalamus wrote:

 [...]


 After a couple more hours today, I found a couple of 
 solutions. Neither is satisfactory.

 [...]


 How about setting the source path directly? With a recent 
 enough dmd version this can be done automatically like here:
 https://github.com/dlang/dmd/pull/5990/files


 Thanks Seb. Has this been included in an official version 
 release yet? (I'm not sure how to tell. I've only used Git a 
 small amount.)

 thanks!


Nope it has been added five days ago.
You might grab a dmd-nightly build from here 
https://dlang.org/download.html
Jul 31 2016
parent reply Seb <seb wilzba.ch> writes:
On Sunday, 31 July 2016 at 16:55:52 UTC, Seb wrote:

 On Sunday, 31 July 2016 at 16:48:52 UTC, Thalamus wrote:

 On Sunday, 31 July 2016 at 16:08:49 UTC, Seb wrote:

 On Sunday, 31 July 2016 at 15:30:46 UTC, Thalamus wrote:

 [...]


 How about setting the source path directly? With a recent 
 enough dmd version this can be done automatically like here:
 https://github.com/dlang/dmd/pull/5990/files


 Thanks Seb. Has this been included in an official version 
 release yet? (I'm not sure how to tell. I've only used Git a 
 small amount.)

 thanks!


 Nope it has been added five days ago.
 You might grab a dmd-nightly build from here 
 https://dlang.org/download.html


To clarify I am talking about ___FILE_FULL_PATH__, maybe 
hard-coding the source directory could also work for you?
Jul 31 2016
parent Thalamus <norobots foo.com> writes:
On Sunday, 31 July 2016 at 17:01:32 UTC, Seb wrote:

 On Sunday, 31 July 2016 at 16:55:52 UTC, Seb wrote:

 On Sunday, 31 July 2016 at 16:48:52 UTC, Thalamus wrote:

 On Sunday, 31 July 2016 at 16:08:49 UTC, Seb wrote:

 On Sunday, 31 July 2016 at 15:30:46 UTC, Thalamus wrote:

 [...]


 How about setting the source path directly? With a recent 
 enough dmd version this can be done automatically like here:
 https://github.com/dlang/dmd/pull/5990/files


 Thanks Seb. Has this been included in an official version 
 release yet? (I'm not sure how to tell. I've only used Git a 
 small amount.)

 thanks!


 Nope it has been added five days ago.
 You might grab a dmd-nightly build from here 
 https://dlang.org/download.html


 To clarify I am talking about ___FILE_FULL_PATH__, maybe 
 hard-coding the source directory could also work for you?


In the end, I elected to go with a separate solution for test 
EXEs with the project hierarchy echoed as solution folders. 
Although this adds some extra overhead to maintain this echo, 
that can be automated as part of the main solution's build. And 
it seems to me that there are inherent advantages to going this 
route. For instance, were this all still in one solution, I'd 
either have to add additional configurations (32-bit w/ -cov, and 
64-bit w/ -cov), or I'd have to manually add -cov to each project 
whenever I wanted coverage info and later remove it, or I'd have 
to wait for the code coverage files to be created after every 
run. A separate solution allows me to maintain -cov for all 
configurations isolated from my main development mode. So it's 
there when I want it and gone when I don't, seamlessly.

Thanks to everyone for their input!
Jul 31 2016