On 9/16/2011 2:18 PM, Andrej Mitrovic wrote:
On 9/17/11, Rainer Schuetze<r.sagita...@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.
Well maybe DMD could tell Mr. Optlink to not do that if I pass
-unittest and -lib. :)
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.
How do I reference this module info?
You can do that by using its mangled name without the preceding
underscore, but extern(C) linkage. Unfortunately, I just noticed itdoes
not work after all, because every unit test gets its own module info
with an unpredictable name (contrary to what's descrined in the ABI
http://d-programming-language.org/abi.html).
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
That works as long as in main I reference a function from the library
(I guess that's where that comment in unittest.d came from, and the
complicated makefile). I'm so-so for this solution.
There is no point in creating a library if you want to link in
everything anyway. You can just build the library module files into a
single object file and add that to your executables' command line.
