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.

On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote:
> 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.

If you agree that to get dmd working one must run it in a specially prepared command prompt, that can work.

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.
>
> [...]

There seems to be a trend here:
Windows devs have problems getting D to install/work correctly on their machines.
Non-windows devs boot up windows and test it and it works fine for them (In this case that was me).

I seriously doubt that much progress will be made here unless some dedicated full-time modern Windows developers take over or at least significantly help with the installer code. Someone like you has years of experience and knowledge about what are good/bad solutions on windows, what workarounds/hacks are OK and which will be abhorrent to users, what will likely break in newer versions of windows/VS etc. etc. etc.

Realistically, no-one except an experienced full-time windows developer is ever going to get this right.

On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote:
> 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.

I also got the same problems.

For LDC is is currently necessary to have VS2015 and fix-up paths like that:

The PATH varible should preferably omit the DMD path and include:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE


The LIB env-variable should have the paths:
    C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64
    C:\Program Files (x86)\Windows Kits\10\lib\10.0.10150.0\ucrt\x64
    C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\lib\um\x64
    C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64

Super-annoying to do so I have a tool that call DUB frontend to do that (it also build Mac bundles).

I'm not sure whose job it is to put things in PATH or LIB. But as it is, everyone that tries will stumble onto this.

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.

I don't use the D installer because I don't trust it to deal with PATH correctly.

On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin wrote:
> On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote:
>> [...]
>
> There seems to be a trend here:
> Windows devs have problems getting D to install/work correctly on their machines.
> Non-windows devs boot up windows and test it and it works fine for them (In this case that was me).
>
> [...]

only talking about dmd here, I didn't try ldc.

On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin wrote:
> Realistically, no-one except an experienced full-time windows developer is ever going to get this right.

It's not a simple tradeoff: Manu's usual requirement is that dmd must work at the utmost ease of use even if heavens crash. Correct behavior is possible, but the question is how much user experience he would like to sacrifice for correctness.

On Friday, 25 September 2015 at 12:17:42 UTC, Kagamin wrote:
> On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin wrote:
>> Realistically, no-one except an experienced full-time windows developer is ever going to get this right.
>
> It's not a simple tradeoff: Manu's usual requirement is that dmd must work at the utmost ease of use even if heavens crash. Correct behavior is possible, but the question is how much user experience he would like to sacrifice for correctness.

The complexity of the tradeoff is exactly why experienced windows developers are necessary here. For example: any tradeoffs I designed would likely be very far from pareto-optimal on windows, let alone be a good solution overall.

Hm, so is the correct approach on Windows to provide separate shell for each application that has console utilities? X_x

On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin wrote:
> There seems to be a trend here:
> Windows devs have problems getting D to install/work correctly on their machines.
> Non-windows devs boot up windows and test it and it works fine for them (In this case that was me).

I was never able to make it work on Windows apart from trivial hello-world. Though I highly suspect my definition of "works" would be very very different from one Manu has in mind.