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. Here's a typical PATH configured for the tools I use in my office: %QTDIR%/bin;%LDC_ROOT%\bin;C:\dev\wxWidgets-3.0.2\lib\gcc_dll;C:\dev\CMake\bin;C:\dev\LLVM\bin;C:\Program Files (x86)\Microsoft VS Code\bin;C:\dev\Python27\;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;c:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\dev\dub;C:\dev\Emscripten\clang\e1.27.0_64bit;C:\dev\Emscripten\node\0.10.17_64bit;C:\dev\Emscripten\python\2.7.5.3_64bit;C:\dev\Emscripten\java\7.45_64bit\bin;C:\dev\Emscripten;C:\dev\Emscripten\emscripten\1.27.0;C:\dev\Emscripten\crunch\1.03;C:\dev\Emscripten\mingw\4.6.2_32bit;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\TortoiseGit\bin;C:\dev\D\dmd2\windows\bin 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? The installer should remember where it installed last time! 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.
