Empty LST files?

[Thalamus via Digitalmars-d-learn]

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!