-
Notifications
You must be signed in to change notification settings - Fork 10
Description
This has been on my mind for awhile: Currently, when installing a DMD, DVM unpacks the archive and then installs by selectively cherry-picking (whitelist-style) files/dirs to copy into an alternate directory structure, and patches sc.ini/dmd.conf accordingly. While it's a nice idea to sanitize DMD into a consistent structure, I'm increasingly of the mind that this creates more maintenance work and trouble than it's worth.
For example, this behavior is the reason why -m32 and -m64 cannot both be used on the same DVM-installed version of DMD (which is increasingly problematic for DVM users now that D's 64-bit support has mostly matured).
Also, there has been some very careful work recently on sc.ini to facilitate using the MS linker. So again, DVM shouldn't risk messing with sc.ini.
The non-DMD-standard directory structure can also make it harder for D novices to get help with installation-related issues on D.learn.
The only thing about DMD's structure that DVM really NEEDS to know is the path to the appropriate "bin" directory. That's much less to deal with as new DMDs are released.
I propose that when DVM installs DMD, it does so by blindly copying the entire structure as-is. Directory trees for other OSes can, of course, be simply omitted or deleted. DVM's auto-generated scripts can simply point to the appropriate bin directory, as keeping track of any variances in "bin" paths is much, much simpler than staying on top of all potentially-problematic changes in DMD's structure and config-files.
On notable benefit of this change is that using both -m32/-m64 on the same DMD should start "just working" for free.