Unittesting in static libraries

[Rainer Schuetze]

On 9/19/2011 3:55 AM, Steven Schveighoffer wrote:
> On Sat, 17 Sep 2011 01:34:35 -0400, Rainer Schuetze <r.sagitario at gmx.de>
> wrote:
>
>> I think the main issue here is that a module that is compiled to a
>> library, is split into a lot of small "object files" (one for each
>> function or global variable) before being combined to the library.
>> This allows the linker to just take the actually referenced parts and
>> leave out anything that is never called.
>>
>> The unit tests are only referenced from the module info, so it might
>> work if you have a reference to it in your main executable.
>> Another workaround would be to build the library in two steps,
>> compiling to normal object files first, then binding these to a
>> library (shameless ad: "separate compile and link" in Visual D):
>>
>> dmd -unittest -c -od. test1.d test2.d
>> dmd -lib -oftest.lib test1.obj test1.obj
>>
>> so it avoids breaking up the modules. the -od. is needed to not just
>> build a single object file.
>
> The output from these lines should be identical to:
>
> dmd -unittest -oftest.lib -lib test1.d test2.d
>
> If it's not, that's a bug.
>

It's different, and it is meant as a feature. As described above, a 
module is split into a number of object files, reducing dependencies 
between the modules in the library.

I'm not sure it is a good feature, though, because it has some side 
effects: the static constructors/destructors in a module are magically 
tied together, but the unittests are not. Also, the debug info is 
missing for classes/structs if the init member is never referenced (see 
http://d.puremagic.com/issues/show_bug.cgi?id=4014 ). Last time I tried, 
disabling the splitting caused other troubles as described in the bug 
report.