Unofficial DVM Windows Beta

[Nick Sabalausky]

"Jacob Carlborg" <doob at me.com> wrote in message 
news:isfqme$17bl$1 at digitalmars.com...
> On 2011-06-05 03:03, Nick Sabalausky wrote:
>>
>> All the technical details you should need to know are up on the Wiki now:
>> https://bitbucket.org/Abscissa256/dvm/wiki/Home
>>
>> Let me know if anything's missing or you're unclear on something (or have
>> any other questions).
>
> I'm still having trouble understanding how the "use" command works, this 
> may just be because I don't know the differences between Posix and Windows 
> in this case. On Posix it behaves like this:
>
> When I run, on the command line, an application or a shell script and it 
> sets environment variables, i.e. PATH, they won't be available to the 
> shell that run the app/script. This is the whole reason for the shell 
> function and "sourcing" a result file on Posix.
>
> Is this not the case when running an application or a batch script on 
> Windows?
>

Ok, just to be clear: My understanding of Posix is that there are two ways 
of running a shell script:

Normally:
./foo.sh

Sourcing it:
. ./foo.sh

The difference between the two is that if the script sets environment vars, 
the "normal" way will keep the env changes private to within the script 
itself, and the "sourcing" way makes them affect the shell that ran the 
script. Right?

On Windows, running a batch file is *always* equivalent to "sourcing" it. 
Batch files do not run in a new instance of the shell. (There is an 
"official" way to write the batch file to make env changes private to within 
the batch itself, but it's really screwy and not really worth bothering 
unless absolutely necessary). Although, if you just simply launch the batch 
file from the GUI, then it'll run in a temporary cmd prompt which closes as 
soon as the batch file finishes, and so naturally, any env changes won't 
outlive that temporary cmd prompt.

Now, running an *executable binary* from the Windows command prompt, I'm 
fairly sure any changes that makes to the environment are *not* visible from 
the command prompt that ran it. (Although I admit I haven't tested that.) 
Therefore, when DVM wants to set the current compiler, it has to use the 
same trick as Posix: launch the DVM binary from a batch file, and then if 
the DVM binary creates a "tmp/result.bat", the batch file will run it and 
the current environment variables will get set for the user's command 
prompt.

The only difference from Posix when setting the current compiler is that 
Windows doesn't support two things:

1. Shell functions. Where you have a "dvm" shell funtion on posix, I just 
simply have a plain old "dvm.bat" (placed inside "[dvm_install_dir]\bin\" so 
that the PATH can find it. And the DVM binary is named _dvm.exe to guarantee 
the batch file gets run instead).

2. Shell startup script. Because of this, Windows can't and doesn't have an 
equivalent of "[dvm_install_dir]/scripts/dvm.sh". Fortunately it's not 
needed, because all of the default paths (ie, the paths to DVM itself and to 
the default compiler) are set in the registry. (Technically, Windows does 
support a shell startup script, but it's really hackish and just not a good 
way to go.)

Does that help?

> Another thing, about the dvm-default-dc and dvm-current-dc scripts. 
> They're actually not really necessary on Posix for DVM to work but they 
> can be used by other applications, like GUI applications.
>

Ahh, I see.

> For example, if you set the current D compiler using "dvm use 2.053" and 
> want to run DMD from your editor. If you just run "dmd" it won't use 
> 2.053, it will use the default D compiler or it won't find DMD. Instead 
> you can refer to the full path of "dvm-current-dc" which will always point 
> to the current D compiler. Similar "dvm-default-dc" will always point the 
> default D compiler. I don't know if Windows has this problem.
>

Sounds like "dvm-current-dc" would be useful on Windows, too, then. I'll add 
it in. Of course, it would always point to the most recent "dvm use xxx" 
from *any* command prompt, but I assume that's the same on Posix, too. I 
can't imagine there'd be any realistic way around that on either OS.

The "dvm-default-dc", however, shouldn't be needed on Windows. Since Windows 
stores the user's PATH and other env vars in the registry instead of a 
shell-specific script like ~/.bashrc, I'm pretty sure that the default 
compiler will work fine even from a GUI app just by running "dmd". 
(Although, come to think of it, I'm going to have to test that...) It should 
pick up the correct path from the user's PATH environment variable just like 
the command prompt would. Although, if the user changes the default compiler 
while the GUI app is running, then to pick up the new changes, the GUI app 
would have to handle the WM_SETTINGCHANGED/"Environment" message: And I 
don't know how common that is (maybe it's automatically handled by the Win 
API?) If that can't be relied on, then maybe "dvm-default-dc" would still be 
useful on Windows too. I'll look into it.