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

[Manu via Digitalmars-d]

On 26 September 2015 at 09:15, Brad Anderson via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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.

Yeah, I think the only one of my complaints in this case that affected
the DMD installer was the uninstallation issue.
It looks like Rainer may have recently fixed this, which is great.

>> 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

My sc.ini is whatever the installer wrote. It works, and it's uneventful.
DMD is working well for me for over a year or so, uninstallation issue
aside. I have come to find DMD reliable in recent years. I think LDC
is the most important toolchain moving forward though, and that needs
all the love it can get.
I wonder if the DMD installer could be repurposed for LDC to use too?
The path wrangling would be equally useful to LDC I think, since it
depends on MSVC too.