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!

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.

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.

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 consisting (thus far) of 17 D and C# projects. Within a single 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!

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 consisting (thus far) of 17 D and C# projects. Within a single 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!

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

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!

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

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?

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!