"Jacob Carlborg" <[email protected]> wrote in message news:[email protected]... > 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.
