Required to link windows header modules (?)

[Sean Kelly]

Walter Bright wrote:
> Sean Kelly wrote:
>> Linking with the windows module present in Phobos isn't a big deal.  
>> But the Windows header project Don has been working on is quite 
>> expansive, and simply importing windows.d ends up pulling in a 
>> substantial chunk of the windows modules.  This slows compilation 
>> noticeably and increases binary size significantly--simply importing 
>> Don's windows.d in my test app made the executable size increase from 
>> ~90K to over 150K.  This appears to be related at least in part to 
>> what appears to be a fixed minimum for importing a module using DMD of 
>> approximately 500 bytes, which I assume is the ModuleInfo data and 
>> similar things.
> 
> It's pretty easy to see what's in a .obj file by running obj2asm on it.

Done that.  And for the smaller modules, the bulk of this does indeed 
appear to be ModuleInfo data.

>> What I find confusing, however, is that I don't appear to need to link 
>> in the standard C modules I've defined in order to use the structs 
>> defined there.  I performed a quick test using struct tm and no 
>> dependency problems came up simply by compiling the test app itself 
>> and linking against a library without std.c.time in it.  Assuming I 
>> didn't mess up the test somehow, can you explain the difference 
>> between this situation and the Windows one?  If it's simply a matter 
>> of having the static initializers available, I'm fine with building 
>> everything, but the inconsistency doesn't seem to make sense.
> 
> You shouldn't need to link in the static initializer for a struct if the 
> static initializer is all 0's.

Ah, that explains the dependencies then, as I believe all of the structs 
I listed have char arrays of some sort in them.  I do still think it's a 
tad odd that the program size would increase by 50K simply for linking 
in the Windows dependencies for a "hello world" program though.  For 
reference, this is the "hello.d" sample from Mango I've been referencing:

http://svn.dsource.org/projects/mango/trunk/example/hello.d

But perhaps it is merely that the Windows headers are a vast 
interdependent mess and this won't be an issue elsewhere.

As a side note, this is also my first experience with using Derek's 
Build program and I have seen reports of it producing unusually large 
executables in the past.  Is it possible that optlink can be tricked to 
not always discard all unnecessary data?  I do find it strange that 
Build could compile an application using DMD and produce a different 
result than if the traditional library method were used.  To this end, 
it does seem possible that a program with more information (ie. the 
compiler) could do a better job at this.  I don't suppose you've 
considered a full compilation approach for DMD?  If dependent modules 
must be opened and parsed anyway, it seems a fairly trivial extension to 
simply compile them as well.  This would actually address a problem I 
noticed with Build in that it isn't able to detect if a module is a 
"header" module and will compile and link the code in anyway, which 
produces "previous definition different" errors at link time.


Sean