On Tue, 28 Nov 2017 19:04:06 +0000, Manuel Maier wrote: > I didn't know about that tool yet, but I like the idea! However, when I > played around with it just now, I ran into the "Cannot find > dmd-2.0.x.x.bat file" issue [1]. And yes, I misread the installation > instructions (thought it said "run <dvm> install dmd"). Then, once dvm > was properly installed, I didn't get that message anymore. I tried > installing dmd 2.076.0 and it apparently succeeded in that, but `dvm use > 2.076.0` didn't appear to do anything... So all in all the application > seems quite rough around the edges and doensn't _feel_ very reliable. > > Another thing I don't think it does is patching the sc.ini with Visual > Studio environment variables, like the dmd installer does. > > [1] https://github.com/jacob-carlborg/dvm/issues/36
dvm works well with cmd; not so much with Powershell. In Powershell, the current directory and working directory are separate; `cd` outside your home folder and execute `Get-Location` and '[environment]::CurrentDirectory` to see them both. Powershell lets you do things like set a registry key (and other non-filesystem objects) as your working directory (`cd HKLM:\SOFTWARE; ls`) This feature is often useful and often annoying, like when using pretty much any application ever written, which generally use the working directory of the parent process (your home folder) [I could be wrong here; dvm builds paths from %APPDATA%, which is in the home folder, but this is the only path issue I know of in Powershell]. The dmd-2.y.z.bat files should be in your path after installing a compiler with dvm, so if you're using dub you can still do `dub build -- compiler=dmd-2.y.z` to choose your compiler (and autocomplete will tell you what you have installed), or if you call dmd directly just call the script and it will pass the arguments forward.
