Am 20.03.2013 15:16, schrieb Robert:

It's not good enough also for a number of other reasons, and the whole concept will also be difficult to get right. For example, suppose we have some dependencies build as dynamic libraries. How should rdmd or any dependency based build tool know where it has to stop when including D modules (i.e. at the border to the dynamic library)? It also needs to support separate compile/link and single file compilation modes for larger projects as a fallback in case of linker issues. Then there is the issue of the additional compiler run to initially determine all dependencies or recompile whenever compilation failed because new dependencies were added and the issue with missing local and string imports ind dmd's .dep files.

These are all reasons why I chose to not rely on rdmd/dependency tracking (and merely included it as a fallback option), but still there are a lot of opposing voices.

Hmm, it seems my assumption about the inner workings of rdmd were right? It just tracks down all needed modules via the imports, locates them and puts them all at the compiler command line? So basically any libraries are ignored? I think I will take the time and study the code a bit more.

AFAIK that's correct.