As some of you may know, there is a dmd package on the chocolatey community feed: https://chocolatey.org/packages/dmd

This makes it as easy as saying...

choco install dmd

... to get dmd on ones machine (once chocolatey is up and running). Unfortunately, this package is well behind the actual latest release of dmd.

I'm currently adding new packages to chocolatey for ldc and dmd.install (i.e. using the dmd windows installer) that update completely automatically using AppVeyor and scheduled builds.

The ldc package seems to work fine so far, since it's just a simple zip file and I can pick up the latest version easily on github (https://api.github.com/repos/ldc-developers/ldc/releases/latest). It's already submitted to the chocolatey community and just needs to be reviewed by a moderator (see here: https://chocolatey.org/packages/ldc).

The dmd.install package, however, is unable to run completely silent, even when I pass /S. This is because the NSIS scripts prompt the user for input with message boxes, ignoring whether the package was invoked as silent or not. For that reason I have created this pull request: https://github.com/dlang/installer/pull/272

The dmd.install chocolatey package can be found here: https://chocolatey.org/packages/dmd.install

I've asked the current maintainer of the dmd chocolatey package to add me as an additional maintainer so that I can include the non-installer version of dmd as an automatically updated package (using http://downloads.dlang.org/releases/LATEST). I also plan to add older versions of dmd for people that require specific versions of dmd.

And finally I also plan to do this for gdc, but I haven't begun work with that one yet. But I think that won't be a problem.

Once all this is up and running, I'll post an announcement about all this. Thought I'd just share what's going on. :)

On Saturday, 25 November 2017 at 23:38:06 UTC, Manuel Maier wrote:
> As some of you may know, there is a dmd package on the chocolatey community feed: https://chocolatey.org/packages/dmd
>
> [...]

Thanks for the work. And ugh about the installer requiring user intervention, I was literally just about to write a script to install dmd on a Windows dev box, remembered I saw something about chocolatey in the NG, and came here to read. Not happy with the current state of affairs...

I reviewed your PR, but I have no merge rights on that repo.

Atila

On 2017-11-28 10:09, Atila Neves wrote:

> Thanks for the work. And ugh about the installer requiring user intervention, I was literally just about to write a script to install dmd on a Windows dev box, remembered I saw something about chocolatey in the NG, and came here to read. Not happy with the current state of affairs...

You can install DMD on Windows using DVM [1].

[1] https://github.com/jacob-carlborg/dvm

-- 
/Jacob Carlborg

On Tuesday, 28 November 2017 at 17:25:35 UTC, Jacob Carlborg wrote:
> On 2017-11-28 10:09, Atila Neves wrote:
>
>> Thanks for the work. And ugh about the installer requiring user intervention, I was literally just about to write a script to install dmd on a Windows dev box, remembered I saw something about chocolatey in the NG, and came here to read. Not happy with the current state of affairs...
>
> You can install DMD on Windows using DVM [1].
>
> [1] https://github.com/jacob-carlborg/dvm

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

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.

On 2017-11-28 20:04, 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.

Please try using cmd instead of PowerShell. BTW, setting a default compiler in cmd using "dmd use <version> -d" will also set it as default for PowerShell. But the standard "use" command doesn't seem to work.

> Another thing I don't think it does is patching the sc.ini with Visual Studio environment variables, like the dmd installer does.

No, it basically only extracts the downloaded archive.

-- 
/Jacob Carlborg

On Wednesday, 29 November 2017 at 01:49:00 UTC, rjframe wrote:
> dvm works well with cmd; not so much with Powershell.

Indeed, I was using powershell! Using cmd now and suddenly it all works.

> 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`)

I've actually come across this myself a couple times already, though I didn't really investigate what the cause of it was. Well now I know.

Thanks for pointing this out! Maybe it would be worthwhile to add some kind of "FAQ" or "Troubleshooting" section to the GitHub README of dvm.

On Wednesday, 29 November 2017 at 16:04:04 UTC, Jacob Carlborg wrote:
> On 2017-11-28 20:04, Manuel Maier wrote:
>> Another thing I don't think it does is patching the sc.ini with Visual Studio environment variables, like the dmd installer does.
>
> No, it basically only extracts the downloaded archive.

That's the one nice thing about the dmd installer, it takes care of setting up the default environment for you if it detects Visual Studio to be installed. I think this is most useful for Windows people coming from Visual Studio who are used to having the environment being set up for them.

I myself am one of these people, but I don't entirely endorse the way Visual Studio solves this problem. I need to decide to either use the Visual Studio GUI, or use one of the "x86 Native Tools Command Prompt" links, or seek out the batch file that sets up the environment for me. So it basically forces you to choose between devenv (which takes a million years to boot) and cmd (which is not what I'd call a inconvenient terminal). The only other option is to basically emulate the VsDevCmd.bat script and manually gather all the necessary info (the very thing the dmd installer does if I'm not mistaken).

If you're not using the digital mars linker, you still have those age old workflow problems, regardless of whether it's C++ or D. And that bugs me quite a bit. I'd love to see a clean solution where the developer has the choice of which environment to use, can quickly switch between these environments, and is able to put them in some kind of manifest to be checked into a git repo or something alike to be shared with fellow developers and CI systems.

P.S.: Sorry for the ranting...

On 2017-11-29 21:44, Manuel Maier wrote:

> Thanks for pointing this out! Maybe it would be worthwhile to add some kind of "FAQ" or "Troubleshooting" section to the GitHub README of dvm.

Done: https://github.com/jacob-carlborg/dvm#limitations

-- 
/Jacob Carlborg

On 2017-11-29 22:16, Manuel Maier wrote:

> That's the one nice thing about the dmd installer, it takes care of setting up the default environment for you if it detects Visual Studio to be installed.

At one point DVM did modify the sc.ini/dmd.conf but for different reasons. But it turned out to be a source of bugs because the upstream config was quite often changed, at the point.

-- 
/Jacob Carlborg