Pathing in the D ecosystem is generally broken (at least on windows)

Brad Anderson via Digitalmars-d digitalmars-d at puremagic.com
Fri Sep 25 16:15:27 PDT 2015


On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote:
> I update DMD yesterday, it couldn't work out where it was 
> installed and the uninstall fails, then complains and errors 
> when trying to install over the failed uninstall, requiring 
> manual intervention.
>
> Then I try and build with LDC, it can't link anymore because 
> paths are
> messed up and when looking for link.exe (microsoft's linker) it 
> finds
> optlink link.exe instead.
> I tried to use a tool in VisualD which disassembles some code, 
> but it
> can't find the tools it needs to do the job!
>
> This is silly. I don't know how such simple things can be so 
> consistently hard?!
> My first and most frequent problems with the D ecosystem were 
> pathing
> issues, and that's still more-or-less the case today.
>
> It's been 6 years for me. I'm getting tired. Can we please make 
> an effort to get the paths right? This might mean some 
> intelligence is required to make it work; check if the tool is 
> the right tool? If it's not, keep looking? If tools can't be 
> found, produce a dialog box prompting the user to supply the 
> proper path to the tool? MSVC interaction (DMD-COFF and LDC) 
> should probably leverage Microsoft's command line scripts, 
> which are located in reliable places, and work reliably. MSCV 
> associated tools shouldn't be capable of finding optlink by 
> mistake.
>
> As a rule, no tool should ever require a windows user to 
> interact with their path variable. It's a colossal mess, 
> windows doesn't do 'PATH'. Mine has an endless list of bin 
> directories, and many/most of them provide duplicates of the 
> same programs. A robust program can never rely on PATH.
>
> [snip]
>
> This is minimal compared to my home dev environment (ie, is a
> controlled office PC).
> Surely this is evidence enough to conclude that no tool should 
> *EVER*
> refer to PATH to find tools?

dmd, as it is installed, doesn't. The installer does detect and 
set the direct paths for all of the Visual C integration with 
sc.ini. It uses the values set by Visual C in the Windows 
registry. It's designed to be idiot proof. It doesn't touch the 
system/user PATH environment variable for this purpose (just the 
PATH dmd itself uses). The installer can optionally update the 
PATH to add dmd (years ago I also added a Visual C Command Window 
style shortcut to the installer for users that didn't want to 
change their PATH).

Take a look at the current sc.ini[1]. It describes how it all 
works. You never have to change your system/user PATH to get 
anything to work.

> The installer should remember where it installed last time!

I just use the defaults so I've never bothered to implement this. 
Pull requests welcome, of course. Sounds trivial.

> This requires action from every tool in the ecosystem, to 
> include a little bit of logic that allows it to validate that 
> paths are configured correctly and that the program _works_, 
> and do something useful or ideally *helpful* if they're not.

Perhaps there are problems in LDC and VisualD but vanilla dmd has 
been pretty solid in this area for awhile now. Rainer just 
recently added support for VS2015. I'm not sure if it's in the 
latest release.

Perhaps you could share your sc.ini and some more information 
about the uninstall error you hit. It's kind of difficult to fix 
any bugs when the description is vague and you seem to be the 
only one experiencing it.

1. 
https://github.com/D-Programming-Language/dmd/blob/master/ini/windows/bin/sc.ini#L31


More information about the Digitalmars-d mailing list