Problems with the DM Toolchain
This page, particularly on templates and library building, is out-of-date and will be cleaned up later.
DM tools have certain issues when it comes to templates and Win32 'headers':
The primary issue for Tango is that Templates cannot be successfully stored and used from within a library. There are specific technical limitations that prevent us from applying this to, for example, char, wchar, and dchar instances of the text-oriented packages.
Secondly: templates and source-code debuggers do not get along on the Win32 platform. The debugger generally gets lost attempting to locate template source. The technical workaround for this is to always alias the templates within the originating module itself, and always relate to said alias instances. However, this causes tremendous code-bloat in the resultant executable (debugging or otherwise) since aliasing instantiated the template, and all instances wind up inside the application.
Thirdly: DMD generates constant initialization data for all structs and classes. This is generally good practice, but falls upon its head when it comes to Win32 header files. An application importing a Win32 header file of any real significance (such as tango.sys.win32.UserGdi) will wind up with a minimum 50KB of initialization data attached. This data is, in general, wholly superfluous for C interfaces (since the C ABI never guaranteed any particular value in an uninitialized struct). Whilst perhaps not an issue for Desktop application, it is certainly one for PocketPC targets.
What we do
We've managed to avoid the Win32 header bloat by placing the Win32 headers into a library (distinct from the primary runtime library), and linking that into the executable instead. For whatever reason, this tends to eliminate the 50KB bloat. The library is called usergdi32.lib, and can be built via a batch file within tango/lib or be generated by the win32 Installer. Note that this library must reside in a place where the linker can find it; typically in dmd/lib along with phobos.lib and various other. The library itself is implicitly linked as necessary, so there's no need to add it to sc.ini or the command line.
Addressing the template issue is handled by keeping them outside of a library. In fact, the entire upper layers of Tango are retained outside of the library, due in part to this issue. To build an application, one must compile all the pertinent Tango files also. In general, this is handled by one of several 'build' style utilities, such as DSSS, Build/Bud, or Jake. The idea behind this is to ensure DMD is provided with a full set of files to compile, typically generated via a set of imports extracted dynamically from the source(s).
Debugging problems remain firmly in the realm of the compiler vendor.