On Friday, 25 September 2015 at 16:43:48 UTC, Mike Parker wrote:
> I use the installer just so I don't have to configure the VS paths, but I tell it not to modify the PATH variable.

Wow, if it has that option, that's cool.

On Friday, 25 September 2015 at 17:47:11 UTC, Kagamin wrote:
> On Friday, 25 September 2015 at 16:30:04 UTC, Jonathan M Davis wrote:
>> I really don't know what the "correct" way to deal with this is in Windows, but the way that it's set up does seem to naturally cause more problems with PATH than you typically get in *nix.
>
> Both work fine until you have conflicts. Imagine you want to use two versions of dmd in parallel.

It is normally solved by embedding version name in a binary and providing symlink to the default (i.e. pytjon2 vs python3)

On Friday, 25 September 2015 at 18:44:08 UTC, Dicebot wrote:
> It is normally solved by embedding version name in a binary and providing symlink to the default (i.e. pytjon2 vs python3)

Not imagine they depend on a third utility, which they assume to be on path and don't provide a way to override its name.

BTW, it's not very difficult to invoke the linker directly.

On Friday, 25 September 2015 at 19:03:16 UTC, Kagamin wrote:
> On Friday, 25 September 2015 at 18:44:08 UTC, Dicebot wrote:
>> It is normally solved by embedding version name in a binary and providing symlink to the default (i.e. pytjon2 vs python3)
>
> Not imagine they depend on a third utility, which they assume to be on path and don't provide a way to override its name.

This is one of many reasons we (package maintainers) don't want to allow developers to do own packaging and distribution ;) It is somewhat common to patch upstream to resolve to proper binary names.

On Friday, 25 September 2015 at 19:32:10 UTC, Dicebot wrote:
> This is one of many reasons we (package maintainers) don't want to allow developers to do own packaging and distribution ;) It is somewhat common to patch upstream to resolve to proper binary names.

With prepared environment it works without making you a compiler developer and devising smart versioning and naming schemes and without deep configurability everywhere.

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

On Friday, 25 September 2015 at 17:48:50 UTC, Kagamin wrote:
> On Friday, 25 September 2015 at 16:43:48 UTC, Mike Parker wrote:
>> I use the installer just so I don't have to configure the VS paths, but I tell it not to modify the PATH variable.
>
> Wow, if it has that option, that's cool.

It has for many releases now. There seems to be some out of date information people have about what the installer does. Here's some of the changes me and others have made over the years.

- Setting the PATH is optional.
- The installer detects and sets the paths to all the necessary Visual C++ stuff in sc.ini.
- The installer provides two shortcuts to command prompts configured with DMD and the necessary Visual Studio paths set up, one for a 32-bit environment and one for a 64-bit environment (just like Visual C++ does). I added this just for people who don't like having their PATH changed but still wanted something that worked out of the box.
- It no longer downloads the zip file and unpacks it, unix stuff and all, into the installation directory. Only the windows specific portion is included and it is embedded inside the installer.
- If it can't detect Visual C++ it offers to download the latest Community Edition for you.
- It can download and install Visual D.
- It warns before uninstalling your old version (in case you've customized your DMD in some way).
- OMF format libcurl is included now.
- It won't nuke the PATH environment variable due to a bug that was in NSIS (this was my first contribution to D years ago).

On Friday, 25 September 2015 at 23:15:29 UTC, Brad Anderson 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.

Looks like Rainer may have already fixed your uninstallation problem[1]. Hard to say though without known more.


1. https://github.com/D-Programming-Language/installer/commit/9d90f955ac30854fcb33a1458e8b7f82549835d9

On Friday, 25 September 2015 at 23:34:21 UTC, Brad Anderson wrote:
> - It won't nuke the PATH environment variable due to a bug that was in NSIS (this was my first contribution to D years ago).

Oh, that was you?
Luckily I kept a copy of each path change, so it was easy to restore. I hope it didn't break too much for other people. :P