Skip to content

Leave DMD directory structure as-is #23

@Abscissa

Description

@Abscissa

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions