Unofficial DVM Windows Beta

[Jacob Carlborg]

On 2011-06-05 22:48, Nick Sabalausky wrote:
> "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?

Yes.

> 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.

Ok, now I understand.

> 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?

That helps, thanks.

>> 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.

Yes, that's how it works on Posix, always points to the most recent "dvm 
use xxx".

> 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.

That would be great, thanks.

-- 
/Jacob Carlborg