DMD v2.066.0-rc1 binaries are available for testing:

    http://wiki.dlang.org/Beta_Testing

Works fine on Windows for my limited tests. The installer directory issue is resolved.

I have two issues, the first of which wouldn't require changes to the RC (phew!). The second issue would require a new RC to resolve but could be considered optional.


First issue:

As part of the installer revamp I took out D1 and DMC and made separate installer scripts for them which the revamped installer will optionally download and install if the user asks for them. This requires installers for D1 and DMC to be built. It's as simple downloading the latest D1 and DMC zips, extracting them, then running:

    makensis /DEmbedD1Dir=<d1dir> /DVersion1=<d1ver> d1-installer.nsi

and

    makensis /DEmbedDmcDir=<dmcdir> /DVersionDmc=<dmcver> dmc-installer.nsi

And uploading the result to the DigitalMars FTP (at least) and the D
download site (ideally). The URLs the D2 installer expects are shown here:
https://github.com/D-Programming-Language/installer/blob/master/windows/d2-installer.nsi#L66

This would only need to be done once and for every new release of D1 and DMC (which are few and far between).

I could do this for you and give you a link to download for you to reupload but I think it's probably more appropriate to have it generated by someone with more official standing. If you'd rather I do it just let me know.


Second issue:

I removed the downloading of Curl from the installer with the goal that we switch to just having it embedded with the rest. The release builder script makes use of Nick's localextras zip. If my understanding is correct we could just add curl to that zip and it'd get included in the release. It's up to you whether to fix this for 2.066 or to just include it in 2.067. In the meantime, end users could just do what they used to do to get curl: download and extract the curl zip on the download page into the installation folder.


On Thu, Jul 31, 2014 at 6:51 AM, Andrew Edwards via dmd-beta < dmd-beta@puremagic.com> wrote:

> DMD v2.066.0-rc1 binaries are available for testing:
>
>     http://wiki.dlang.org/Beta_Testing
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 8/1/14, 3:26 AM, Brad Anderson wrote:
> Works fine on Windows for my limited tests. The installer directory issue is resolved.
>
> I have two issues, the first of which wouldn't require changes to the RC (phew!). The second issue would require a new RC to resolve but could be considered optional.
>
Let's go ahead and fixing issue #2 for 2.066. We will need to produce another RC anyway: there are at least three other issues that must be addressed and tested prior to the final release.

As for issue #1, I have no problems creating the installers as outlined below. I'll build and have them uploaded when I prepare RC2. My problem will stem from knowing when to build D1 in the future because it never really crosses my mind as something that needs to be done. But I'm sure Walter or someone else will alert me when it's necessary to do so.
>
> First issue:
>
> As part of the installer revamp I took out D1 and DMC and made separate installer scripts for them which the revamped installer will optionally download and install if the user asks for them. This requires installers for D1 and DMC to be built. It's as simple downloading the latest D1 and DMC zips, extracting them, then running:
>
>     makensis /DEmbedD1Dir=<d1dir> /DVersion1=<d1ver> d1-installer.nsi
>
> and
>
>     makensis /DEmbedDmcDir=<dmcdir> /DVersionDmc=<dmcver>
> dmc-installer.nsi
>
> And uploading the result to the DigitalMars FTP (at least) and the D download site (ideally). The URLs the D2 installer expects are shown here: https://github.com/D-Programming-Language/installer/blob/master/windows/d2-installer.nsi#L66
>
> This would only need to be done once and for every new release of D1 and DMC (which are few and far between).
>
> I could do this for you and give you a link to download for you to reupload but I think it's probably more appropriate to have it generated by someone with more official standing. If you'd rather I do it just let me know.
>
>
> Second issue:
>
> I removed the downloading of Curl from the installer with the goal that we switch to just having it embedded with the rest. The release builder script makes use of Nick's localextras zip. If my understanding is correct we could just add curl to that zip and it'd get included in the release. It's up to you whether to fix this for 2.066 or to just include it in 2.067. In the meantime, end users could just do what they used to do to get curl: download and extract the curl zip on the download page into the installation folder.
>
>
> On Thu, Jul 31, 2014 at 6:51 AM, Andrew Edwards via dmd-beta <dmd-beta@puremagic.com <mailto:dmd-beta@puremagic.com>> wrote:
>
>     DMD v2.066.0-rc1 binaries are available for testing:
>
>     http://wiki.dlang.org/Beta_Testing
>     _______________________________________________
>     dmd-beta mailing list
>     dmd-beta@puremagic.com <mailto:dmd-beta@puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>

On 7/31/2014 5:51 AM, Andrew Edwards wrote:
> DMD v2.066.0-rc1 binaries are available for testing:
>
>      http://wiki.dlang.org/Beta_Testing

Thank you again, Andrew!

Also can someone please review https://github.com/D-Programming-Language/phobos/pull/2374 ? Missing this in release will result in regression issue being filed almost inevitably.

On Thu, Jul 31, 2014 at 2:51 PM, Andrew Edwards via dmd-beta < dmd-beta@puremagic.com> wrote:

> DMD v2.066.0-rc1 binaries are available for testing:
>
>     http://wiki.dlang.org/Beta_Testing
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Thursday, 31 July 2014 at 12:51:53 UTC, Andrew Edwards wrote:
> DMD v2.066.0-rc1 binaries are available for testing:
>
>     http://wiki.dlang.org/Beta_Testing

Want to bring attention of wider audience that this release really needs all help it can get - regression count still stays high as new ones get fired after old ones are fixed and schedule is long overdue. Any help will be appreciated.

This windiows installer went wrong on me.
First, it tried to uninstall, it offered to uninstall from 'C:\D'. My DMD
install is 'C:\dev\D'... The path was presented in a greyed out textbox
that I couldn't type in to correct it, and no button to select the true
install location.
The uninstall step failed.

Then when reinstalling I was given the option where to install, I chose 'C:\dev\D' and it installed over the top of my existing install, and wiped my sc.ini file. So I need to configure the DirectX SDK paths again.


Side note:
I still think the installer really should detect the DXSDK; it's a
Microsoft library, and virtually any multimedia software developed with
VS2010 or prior will depend on it (It's merged into the WinSDK since
DX2012).

The DXSDK install paths are:
Include: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include
Lib: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x64

The "(June 2010)" part is a safe assumption, it's the last released one,
and it will remain so since it's now bundled with the WinSDK for more
recent visual studio releases. It's the only one available on the Microsoft
website.
As I see it, if we profess to support VS2010 and prior, then we should
detect the DXSDK paths in the installer, otherwise software that builds
fine in VS2012+ won't work with VS2010 without user intervention, and that
will almost certainly lead to posts on this forum.


On 4 August 2014 11:12, Dicebot via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Thursday, 31 July 2014 at 12:51:53 UTC, Andrew Edwards wrote:
>
>> DMD v2.066.0-rc1 binaries are available for testing:
>>
>>     http://wiki.dlang.org/Beta_Testing
>>
>
> Want to bring attention of wider audience that this release really needs all help it can get - regression count still stays high as new ones get fired after old ones are fixed and schedule is long overdue. Any help will be appreciated.
>

On 8/3/2014 8:51 PM, Manu via Digitalmars-d-announce wrote:
> This windiows installer went wrong on me.
> First, it tried to uninstall, it offered to uninstall from 'C:\D'. My DMD
> install is 'C:\dev\D'... The path was presented in a greyed out textbox that I
> couldn't type in to correct it, and no button to select the true install location.
> The uninstall step failed.
>
> Then when reinstalling I was given the option where to install, I chose
> 'C:\dev\D' and it installed over the top of my existing install, and wiped my
> sc.ini file. So I need to configure the DirectX SDK paths again.

Please file these on bugzilla as 2 bug reports.

https://issues.dlang.org/enter_bug.cgi


> Side note:
> I still think the installer really should detect the DXSDK; it's a Microsoft
> library, and virtually any multimedia software developed with VS2010 or prior
> will depend on it (It's merged into the WinSDK since DX2012).
>
> The DXSDK install paths are:
> Include: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include
> Lib: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x64
>
> The "(June 2010)" part is a safe assumption, it's the last released one, and it
> will remain so since it's now bundled with the WinSDK for more recent visual
> studio releases. It's the only one available on the Microsoft website.
> As I see it, if we profess to support VS2010 and prior, then we should detect
> the DXSDK paths in the installer, otherwise software that builds fine in VS2012+
> won't work with VS2010 without user intervention, and that will almost certainly
> lead to posts on this forum.

One of the reasons I delayed so long in supporting VS is because Microsoft changes things around with every release, making trying to support whatever version the customer has is a constant configuration/testing nightmare, consuming a great deal of time and effort with little payback.

With dmc, this is not a problem.

As an aside, one thing I find difficult to understand is why experienced C++ developers find it so hard to set an environment variable (or one in the sc.ini) pointing to where the right .h files are and the right .lib files are.

Heck, I just cribbed them from where Microsoft set them in its own command prompt shortcut "Visual Studio x64 Win64 Command Prompt (2010)". For example, clicking on the shortcut and typing "set" gives:

--------------------------------------

Setting environment for using Microsoft Visual Studio 2010 x64 tools.

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>set
ALLUSERSPROFILE=C:\ProgramData
CommandPromptType=Native
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
ComSpec=C:\Windows\system32\cmd.exe
FP_NO_HOST_CHECK=NO
Framework35Version=v3.5
FrameworkDir=C:\Windows\Microsoft.NET\Framework64
FrameworkDIR64=C:\Windows\Microsoft.NET\Framework64
FrameworkVersion=v4.0.30319
FrameworkVersion64=v4.0.30319
FSHARPINSTALLDIR=C:\Program Files (x86)\Microsoft F#\v4.0\
HOMEDRIVE=C:
HOMEPATH=\Users\walter
INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files (x86)\Micros
oft Visual Studio 10.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include
;
LIB=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\LIB\amd64;C:\Program Files (x86)\Microsof
t Visual Studio 10.0\VC\ATLMFC\LIB\amd64;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\lib\x64
;
LIBPATH=C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Windows\Microsoft.NET\Framework64\v3.5;C:
\Program Files (x86)\Microsoft Visual Studio 10.0\VC\LIB\amd64;C:\Program Files (x86)\Microsoft Visu
al Studio 10.0\VC\ATLMFC\LIB\amd64;
MEDIAMALL=C:\Program Files (x86)\MediaMall\
MOZ_PLUGIN_PATH=C:\Program Files (x86)\Foxit Software\Foxit Reader\plugins\
NUMBER_OF_PROCESSORS=6
OS=Windows_NT
Path=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64;C:\Windows\Microsoft.NET\Frame
work64\v4.0.30319;C:\Windows\Microsoft.NET\Framework64\v3.5;C:\Program Files (x86)\Microsoft Visual
Studio 10.0\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE;C:\Program
 Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools;C:\Program Files (x86)\HTML Help Workshop;C:
\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\x64;C:\Program Files (x86)\Mic
rosoft SDKs\Windows\v7.0A\bin\x64;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin;C:\Program
 Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shar
ed\Windows Live;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsP
owerShell\v1.0\;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microso
ft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (
x86)\Windows Live\Shared
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
Platform=X64
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 1 Stepping 2, AuthenticAMD
PROCESSOR_LEVEL=21
PROCESSOR_REVISION=0102
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\Windows
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\
VS100COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\
VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\
windir=C:\Windows
WindowsSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\
windows_tracing_flags=3
windows_tracing_logfile=C:\BVTBin\Tests\installpackage\csilogfile.log

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>
----------------------------------

There's VCINSTALLDIR and WindowsSdkDir and INCLUDE and LIBPATH

On 6 August 2014 15:20, Walter Bright via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On 8/3/2014 8:51 PM, Manu via Digitalmars-d-announce wrote:
>
>> This windiows installer went wrong on me.
>> First, it tried to uninstall, it offered to uninstall from 'C:\D'. My DMD
>> install is 'C:\dev\D'... The path was presented in a greyed out textbox
>> that I
>> couldn't type in to correct it, and no button to select the true install
>> location.
>> The uninstall step failed.
>>
>> Then when reinstalling I was given the option where to install, I chose
>> 'C:\dev\D' and it installed over the top of my existing install, and
>> wiped my
>> sc.ini file. So I need to configure the DirectX SDK paths again.
>>
>
> Please file these on bugzilla as 2 bug reports.
>
> https://issues.dlang.org/enter_bug.cgi


Yup, there's already been listings and related discussions.


As an aside, one thing I find difficult to understand is why experienced
> C++ developers find it so hard to set an environment variable (or one in the sc.ini) pointing to where the right .h files are and the right .lib files are.
>

There is %DXSDK_DIR%, which is fine to use.
I've been discussing it with Brad on the bug tracker.

On Wednesday, 6 August 2014 at 05:20:27 UTC, Walter Bright wrote:
> On 8/3/2014 8:51 PM, Manu via Digitalmars-d-announce wrote:
>> This windiows installer went wrong on me.
>> First, it tried to uninstall, it offered to uninstall from 'C:\D'. My DMD
>> install is 'C:\dev\D'... The path was presented in a greyed out textbox that I
>> couldn't type in to correct it, and no button to select the true install location.
>> The uninstall step failed.
>>
>> Then when reinstalling I was given the option where to install, I chose
>> 'C:\dev\D' and it installed over the top of my existing install, and wiped my
>> sc.ini file. So I need to configure the DirectX SDK paths again.
>
> Please file these on bugzilla as 2 bug reports.
>
> https://issues.dlang.org/enter_bug.cgi
>
>
>> Side note:
>> I still think the installer really should detect the DXSDK; it's a Microsoft
>> library, and virtually any multimedia software developed with VS2010 or prior
>> will depend on it (It's merged into the WinSDK since DX2012).
>>
>> The DXSDK install paths are:
>> Include: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include
>> Lib: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x64
>>
>> The "(June 2010)" part is a safe assumption, it's the last released one, and it
>> will remain so since it's now bundled with the WinSDK for more recent visual
>> studio releases. It's the only one available on the Microsoft website.
>> As I see it, if we profess to support VS2010 and prior, then we should detect
>> the DXSDK paths in the installer, otherwise software that builds fine in VS2012+
>> won't work with VS2010 without user intervention, and that will almost certainly
>> lead to posts on this forum.
>
> One of the reasons I delayed so long in supporting VS is because Microsoft changes things around with every release, making trying to support whatever version the customer has is a constant configuration/testing nightmare, consuming a great deal of time and effort with little payback.
>
> With dmc, this is not a problem.
>
> As an aside, one thing I find difficult to understand is why experienced C++ developers find it so hard to set an environment variable (or one in the sc.ini) pointing to where the right .h files are and the right .lib files are.

I don't think it's difficult for them, I think they often just don't know they can. Environment variables just aren't as well known on Windows these days. If you are an 18 year old getting into programming you likely have never even heard of environment variables or batch files and may not even know how to use the command prompt (or open it for that matter). Windows Vista came out when they were 10 years old and the days of having to know and use the command prompt for typical users were long gone by this point. I'm thirty so I knew and used MS-DOS as a kid (I had to) but if you've never used these things how would you know you could?

Even if you are an experienced programmer having used Visual Studio or some other IDE for years you'd likely not have had to adjust environment variables to get anything to work.

Manu knows these things, of course, but his it-should-just-work complaints probably go a long way to helping people who don't know these things.


> Heck, I just cribbed them from where Microsoft set them in its own command prompt shortcut "Visual Studio x64 Win64 Command Prompt (2010)". For example, clicking on the shortcut and typing "set" gives:
>
> [...]

I added the same style of command prompt for DMD to the installer a couple years ago. One for 64-bit and one for 32-bit.