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
