Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
September 25, 2015 Pathing in the D ecosystem is generally broken (at least on windows) | ||||
---|---|---|---|---|
| ||||
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. |
September 25, 2015 Re: Pathing in the D ecosystem is generally broken (at least on windows) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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.
|
September 25, 2015 Re: Pathing in the D ecosystem is generally broken (at least on windows) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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.
|
September 25, 2015 Re: Pathing in the D ecosystem is generally broken (at least on windows) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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. |
September 25, 2015 Re: Pathing in the D ecosystem is generally broken (at least on windows) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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.
|
September 25, 2015 Re: Pathing in the D ecosystem is generally broken (at least on windows) | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | 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.
|
September 25, 2015 Re: Pathing in the D ecosystem is generally broken (at least on windows) | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | 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.
|
September 25, 2015 Re: Pathing in the D ecosystem is generally broken (at least on windows) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | 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.
|
September 25, 2015 Re: Pathing in the D ecosystem is generally broken (at least on windows) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | Hm, so is the correct approach on Windows to provide separate shell for each application that has console utilities? X_x |
September 25, 2015 Re: Pathing in the D ecosystem is generally broken (at least on windows) | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | 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.
|
Copyright © 1999-2021 by the D Language Foundation