www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD VS2017 Support

reply Jolly James <j.j jmail.com> writes:
DMD does not support VS2017. Therefore I cannot link x64 
applications. DMD installer only offers to install VS2013 (what I 
am absolutely not going to do, as that would be a real shame with 
the disk space it consumes).

Any plans for supporting VS2017?
Apr 19 2017
parent reply Jolly James <j.j jmail.com> writes:
I cannot even fix it myself because DMD is looking for 
"bin\link.exe". But with VS2017 the path would actually be 
something like "\bin\HostX64\x64".
Apr 19 2017
next sibling parent Mike B Johnson <Mikey Ikes.com> writes:
On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:

 I cannot even fix it myself because DMD is looking for 
 "bin\link.exe". But with VS2017 the path would actually be 
 something like "\bin\HostX64\x64".


Edit your sc.ini in the dmd\windows\bin dir or use junctions to 
map directories.

DMD's config system is ancient and they refuse to update it 
because once you set it up and don't change your system you don't 
have to do much else. It's sort of like a rite of passage, I 
guess to weed out the losers.
Apr 19 2017
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:

 I cannot even fix it myself because DMD is looking for 
 "bin\link.exe". But with VS2017 the path would actually be 
 something like "\bin\HostX64\x64".


Please ignore Mike's answer. Visual D is maintained by Rainers 
Schuetze and is hosted here[1] on github. From the readme:

For more information on installation, a quick tour of Visual D 
with some screen shots and feedback, please visit the project 
home for Visual D at 
http://rainers.github.io/visuald/visuald/StartPage.html.

There's a forum dedicated to IDE discussions 
(http://forum.dlang.org/group/digitalmars.D.ide), where you can 
leave your comments and suggestions. Bug reports can be filed to 
the D bugzilla database for Component VisualD.

Have fun, Rainer Schuetze

1. https://github.com/dlang/visuald
Apr 19 2017
next sibling parent reply Jolly James <j.j jmail.com> writes:
On Thursday, 20 April 2017 at 00:13:29 UTC, Meta wrote:

 On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:

 [...]


 Please ignore Mike's answer. Visual D is maintained by Rainers 
 Schuetze and is hosted here[1] on github. From the readme:

 For more information on installation, a quick tour of Visual D 
 with some screen shots and feedback, please visit the project 
 home for Visual D at 
 http://rainers.github.io/visuald/visuald/StartPage.html.

 There's a forum dedicated to IDE discussions 
 (http://forum.dlang.org/group/digitalmars.D.ide), where you can 
 leave your comments and suggestions. Bug reports can be filed 
 to the D bugzilla database for Component VisualD.

 Have fun, Rainer Schuetze

 1. https://github.com/dlang/visuald


What has the DMD compiler to do with a VS plugin that I am not 
using?
Apr 20 2017
parent reply Meta <jared771 gmail.com> writes:
On Thursday, 20 April 2017 at 14:29:28 UTC, Jolly James wrote:

 What has the DMD compiler to do with a VS plugin that I am not 
 using?


You said in your original post "DMD installer only offers to 
install VS2013". This isn't the DMD installer but the Visual D 
installer that installs the plugin for the appropriate version of 
Visual Studio. As Mike said, though, you can also just edit 
sc.ini if you don't want to use Visual D.
Apr 20 2017
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 20 April 2017 at 14:44:54 UTC, Meta wrote:

 On Thursday, 20 April 2017 at 14:29:28 UTC, Jolly James wrote:

 What has the DMD compiler to do with a VS plugin that I am not 
 using?


 You said in your original post "DMD installer only offers to 
 install VS2013". This isn't the DMD installer but the Visual D 
 installer that installs the plugin for the appropriate version 
 of Visual Studio. As Mike said, though, you can also just edit 
 sc.ini if you don't want to use Visual D.


It actually does offer to install both VS 2013 and Visual D.
Apr 20 2017
parent reply Meta <jared771 gmail.com> writes:
On Thursday, 20 April 2017 at 17:06:15 UTC, Mike Parker wrote:

 On Thursday, 20 April 2017 at 14:44:54 UTC, Meta wrote:

 On Thursday, 20 April 2017 at 14:29:28 UTC, Jolly James wrote:

 What has the DMD compiler to do with a VS plugin that I am 
 not using?


 You said in your original post "DMD installer only offers to 
 install VS2013". This isn't the DMD installer but the Visual D 
 installer that installs the plugin for the appropriate version 
 of Visual Studio. As Mike said, though, you can also just edit 
 sc.ini if you don't want to use Visual D.


 It actually does offer to install both VS 2013 and Visual D.


Wow, I did not know that. Seems a little excessive.
Apr 20 2017
parent Jolly James <j.j jmail.com> writes:
On Thursday, 20 April 2017 at 17:10:05 UTC, Meta wrote:

 On Thursday, 20 April 2017 at 17:06:15 UTC, Mike Parker wrote:

 On Thursday, 20 April 2017 at 14:44:54 UTC, Meta wrote:

 On Thursday, 20 April 2017 at 14:29:28 UTC, Jolly James wrote:

 What has the DMD compiler to do with a VS plugin that I am 
 not using?


 You said in your original post "DMD installer only offers to 
 install VS2013". This isn't the DMD installer but the Visual 
 D installer that installs the plugin for the appropriate 
 version of Visual Studio. As Mike said, though, you can also 
 just edit sc.ini if you don't want to use Visual D.


 It actually does offer to install both VS 2013 and Visual D.


 Wow, I did not know that. Seems a little excessive.


But anyway, that's how it is.

By the way: installing VS2013 is only offered to you, if no 
compatible version (atm VS2015 or older) is found on your machine.
Apr 20 2017
prev sibling parent Mike B Johnson <Mikey Ikes.com> writes:
On Thursday, 20 April 2017 at 00:13:29 UTC, Meta wrote:

 On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:

 I cannot even fix it myself because DMD is looking for 
 "bin\link.exe". But with VS2017 the path would actually be 
 something like "\bin\HostX64\x64".


 Please ignore Mike's answer. Visual D is maintained by Rainers 
 Schuetze and is hosted here[1] on github. From the readme:


Why should I be ignored? Specially when I'm right?
Apr 20 2017
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:

 I cannot even fix it myself because DMD is looking for 
 "bin\link.exe". But with VS2017 the path would actually be 
 something like "\bin\HostX64\x64".


You can install the MS Build Tools 2015. DMD will work with that. 
You have two options to do so -- download the installer at the 
link below or run the VS 2017 installer and select it in the 
"Individual Components" tab. I'm on my MacBook now and can't 
recall exactly, but it may be listed as some thing like "Platform 
toolset v140". With both options, you have the added benefit that 
you can choose to use either the 2015 or 2017 build tools when 
compiling C & C++ projects in VS 2017  (and, I assume, Visual D).

https://www.microsoft.com/en-us/download/details.aspx?id=48159
Apr 19 2017
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 20 April 2017 at 04:58:55 UTC, Mike Parker wrote:

 You can install the MS Build Tools 2015. DMD will work with 
 that. You have two options to do so -- download the installer 
 at the link below or run the VS 2017 installer and select it in 
 the "Individual Components" tab. I'm on my MacBook now and 
 can't recall exactly, but it may be listed as some thing like 
 "Platform toolset v140". With both options, you have the added 
 benefit that you can choose to use either the 2015 or 2017 
 build tools when compiling C & C++ projects in VS 2017  (and, I 
 assume, Visual D).

 https://www.microsoft.com/en-us/download/details.aspx?id=48159


I should add that Mike's suggestion to edit sc.ini should do the 
trick, but I find it convenient to have both toolsets installed.
Apr 19 2017
parent Jolly James <j.j jmail.com> writes:
On Thursday, 20 April 2017 at 05:02:37 UTC, Mike Parker wrote:

 On Thursday, 20 April 2017 at 04:58:55 UTC, Mike Parker wrote:

 [...]


 I should add that Mike's suggestion to edit sc.ini should do 
 the trick, but I find it convenient to have both toolsets 
 installed.


I'll give it a try, thanks to you and Mike J.! 👍🏻
Apr 20 2017
prev sibling parent reply NotSpooky <zoteman94 gmail.com> writes:
On Thursday, 20 April 2017 at 04:58:55 UTC, Mike Parker wrote:

 You can install the MS Build Tools 2015. DMD will work with 
 that.


I'd be very nice if instead of offering to install VS, it offered 
the build tools. Also mentioning which installations are 
compatible so that the user can select the one he/she prefers.

A lot of people are confused with this.
Apr 21 2017
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 21 April 2017 at 14:37:40 UTC, NotSpooky wrote:


 I'd be very nice if instead of offering to install VS, it 
 offered the build tools. Also mentioning which installations 
 are compatible so that the user can select the one he/she 
 prefers.

 A lot of people are confused with this.


There's no issue with compatibility. DMD is perfectly compatible 
with all recent versions of VS, including 2017. The issue is that 
2017 has changed its directory tree and the DMD *installer* can't 
pick it up automatically. Now that the breakage is known, the 
next the installer will be updated and the next (hopefully) DMD 
release will include it.
Apr 21 2017
parent reply NotSpooky <zoteman94 gmail.com> writes:
On Saturday, 22 April 2017 at 02:13:09 UTC, Mike Parker wrote:


 There's no issue with compatibility. DMD is perfectly 
 compatible with all recent versions of VS, including 2017. The 
 issue is that 2017 has changed its directory tree and the DMD 
 *installer* can't pick it up automatically. Now that the 
 breakage is known, the next the installer will be updated and 
 the next (hopefully) DMD release will include it.


Oh ok so it works with all of them.

I don't have Windows so I don't know if this has changed, but 
last time I tried to install dmd there it asked to install VS 
2013, I know some people that didn't want to install DMD because 
VS is huge, now that the build tools are an option maybe that's 
the one the installer should suggest (or maybe even suggest both).
Apr 21 2017
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Saturday, 22 April 2017 at 02:22:56 UTC, NotSpooky wrote:

 On Saturday, 22 April 2017 at 02:13:09 UTC, Mike Parker wrote:


 There's no issue with compatibility. DMD is perfectly 
 compatible with all recent versions of VS, including 2017. The 
 issue is that 2017 has changed its directory tree and the DMD 
 *installer* can't pick it up automatically. Now that the 
 breakage is known, the next the installer will be updated and 
 the next (hopefully) DMD release will include it.


 Oh ok so it works with all of them.

 I don't have Windows so I don't know if this has changed, but 
 last time I tried to install dmd there it asked to install VS 
 2013, I know some people that didn't want to install DMD 
 because VS is huge, now that the build tools are an option 
 maybe that's the one the installer should suggest (or maybe 
 even suggest both).


That was discussed so many times... DMD don't need VS itself but 
rather compilers and tools, which is included in Windows SDK's, 
and takes just 4GB or so.
But this is not an issue for anyone dealing with native 
development on Windows since all this stuff is neccessary.

Also VS 2017 is much more modular now, so its now lighter than 
ever before.
but of course for C++ (and D) you still need Windows SDK.

IIRC D also can be used without VS or WinSDK at all, just forget 
about m32mscoff and x64 builds
Apr 21 2017
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 22 April 2017 at 02:39:41 UTC, evilrat wrote:


 Also VS 2017 is much more modular now, so its now lighter than 
 ever before.
 but of course for C++ (and D) you still need Windows SDK.


The SDK stuff is installed with VS.


 IIRC D also can be used without VS or WinSDK at all, just 
 forget about m32mscoff and x64 builds


Yes, that is correct. But that comes with its own headaches.
Apr 21 2017
parent reply Igor <stojkovic.igor gmail.com> writes:
On Saturday, 22 April 2017 at 02:46:30 UTC, Mike Parker wrote:

 On Saturday, 22 April 2017 at 02:39:41 UTC, evilrat wrote:


 Also VS 2017 is much more modular now, so its now lighter than 
 ever before.
 but of course for C++ (and D) you still need Windows SDK.


 The SDK stuff is installed with VS.


 IIRC D also can be used without VS or WinSDK at all, just 
 forget about m32mscoff and x64 builds


 Yes, that is correct. But that comes with its own headaches.


I had a working VS 2015 with VisualD and DMD. Today I uninstalled 
VS2015 and VisualD, then installed VS2017 and latest VisualD but 
when I create new D windows app and try to run it I get this 
error:

Command Line

set PATH=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86;C:\Program
Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE;C:\Program Files
(x86)\Windows Kits\8.1\bin\x86;.\windows\bin;%PATH%
dmd -g -debug -X -Xf"Win32\Debug\testapp.json" 
-deps="Win32\Debug\testapp.dep" -c -of"Win32\Debug\testapp.obj" 
winmain.d
if errorlevel 1 goto reportError

set LIB=
echo. > D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo 
"Win32\Debug\testapp.obj","Win32\Debug\testapp.exe","Win32\Debug\tes
app.map",ole32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo kernel32.lib+ >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo user32.lib+ >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo comctl32.lib+ >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo comdlg32.lib+ >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo user32.lib+ >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo kernel32.lib/NOMAP/CO/NOI/DELEXE /SUBSYSTEM:WINDOWS >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg

"C:\Program Files (x86)\VisualD\pipedmd.exe" -deps 
Win32\Debug\testapp.lnkdep link.exe 
 D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
if errorlevel 1 goto reportError
if not exist "Win32\Debug\testapp.exe" (echo 
"Win32\Debug\testapp.exe" not created! && goto reportError)

goto noError

:reportError
echo Building Win32\Debug\testapp.exe failed!

:noError
Output

Microsoft (R) Incremental Linker Version 14.10.25019.0
Copyright (C) Microsoft Corporation.  All rights reserved.

"Win32\Debug\testapp.obj,Win32\Debug\testapp.exe,Win32\Debug\testapp.map,ole32.lib+"
kernel32.lib+
user32.lib+
comctl32.lib+
comdlg32.lib+
user32.lib+
kernel32.lib/NOMAP/CO/NOI/DELEXE /SUBSYSTEM:WINDOWS
LINK : fatal error LNK1181: cannot open input file 
'Win32\Debug\testapp.obj,Win32\Debug\testapp.exe,Win32\Debug\testapp.map,ole32.lib+'
Building Win32\Debug\testapp.exe failed!

I tried updating sc.ini to new paths but I still get this error. 
Can someone offer some advice?
Apr 30 2017
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 30 April 2017 at 14:56:44 UTC, Igor wrote:


 I tried updating sc.ini to new paths but I still get this 
 error. Can someone offer some advice?


Which paths did you set?
Apr 30 2017
parent reply Igor <stojkovic.igor gmail.com> writes:
On Sunday, 30 April 2017 at 15:53:07 UTC, Mike Parker wrote:

 On Sunday, 30 April 2017 at 14:56:44 UTC, Igor wrote:


 I tried updating sc.ini to new paths but I still get this 
 error. Can someone offer some advice?


 Which paths did you set?


These are the ones I changed:

VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\VC\Tools\MSVC\14.10.25017\
UCRTVersion=10.0.15063.0

LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe

PATH=%PATH%;%VCINSTALLDIR%\bin\HostX64\x64

LIB=%LIB%;"%VCINSTALLDIR%\lib\x64"

Same for x86 environment, except, of course I replaced x64 with 
x86 in the values.

I should also mention that compiling using DUB works. It only 
doesn't work from VS.
Apr 30 2017
next sibling parent reply John Chapman <johnch_atms hotmail.com> writes:
On Sunday, 30 April 2017 at 16:05:10 UTC, Igor wrote:

 On Sunday, 30 April 2017 at 15:53:07 UTC, Mike Parker wrote:

 On Sunday, 30 April 2017 at 14:56:44 UTC, Igor wrote:


 I tried updating sc.ini to new paths but I still get this 
 error. Can someone offer some advice?


 Which paths did you set?


 These are the ones I changed:

 VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual 
 Studio\2017\Community\VC\Tools\MSVC\14.10.25017\
 UCRTVersion=10.0.15063.0

 LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe

 PATH=%PATH%;%VCINSTALLDIR%\bin\HostX64\x64

 LIB=%LIB%;"%VCINSTALLDIR%\lib\x64"

 Same for x86 environment, except, of course I replaced x64 with 
 x86 in the values.

 I should also mention that compiling using DUB works. It only 
 doesn't work from VS.


Here are mine, if it helps:

VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\VC
WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10
UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10
UCRTVersion=10.0.15063.0
LINKCMD=%VCINSTALLDIR%\Tools\MSVC\14.10.25017\bin\HostX64\x64\link.exe
PATH=%PATH%;%VCINSTALLDIR%\Tools\MSVC\14.10.25017\bin\HostX64\x64
LIB=%LIB%;"%VCINSTALLDIR%\Tools\MSVC\14.10.25017\lib\x64"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x64"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
Apr 30 2017
parent reply Igor <stojkovic.igor gmail.com> writes:
On Sunday, 30 April 2017 at 16:31:13 UTC, John Chapman wrote:

 Here are mine, if it helps:


I tried but still the same problem. I also tried reinstalling 
VisualD after changing sc.ini in DMD but that didn't help either.
Apr 30 2017
parent Mike B Johnson <Mikey Ikes.com> writes:
On Sunday, 30 April 2017 at 16:52:52 UTC, Igor wrote:

 On Sunday, 30 April 2017 at 16:31:13 UTC, John Chapman wrote:

 Here are mine, if it helps:


 I tried but still the same problem. I also tried reinstalling 
 VisualD after changing sc.ini in DMD but that didn't help 
 either.


You are going to have to figure it out. Visual Studio does some 
stupid path stuff that doesn't make any sense really(seems like 
it could do a much better job).

What you could do is:

1. Create a "library" folder.

e.g.,

C:\DMD\Libs\Coff\x86
C:\DMD\Libs\Coff\x64
C:\DMD\Libs\OMF\x86
C:\DMD\Libs\OMF\x64 <- not used as there is no x64 omf


2. Point sc.ini to these.

3. Copy the lib files from the VS or win SDK to these folders.

4. Do the magic that it takes to get it to work(which is finding 
the right libs that are needed, using procmon to see where dmd is 
looking, etc). This involves building and checking the errors 
then trying to resolve them.


Once done, you have a solid set of libs that once works, won't 
change.  When you update VS you can update the libs here and 
there but it is not needed very often.

Sometimes you'll have to pull in different libs from different 
versions and such. DMD comes with the some libs that you can use 
for x86.

Once you get it working you shouldn't have to mess with it much. 
If you accidentally overwrite sc.ini(which is ridiculous that it 
does this on install), you know EXACTLY where the libs are and 
don't have to go hunt for them again. If you want, you can use 
junctions instead of copying but these might need to be updated 
again when VS changes.
Apr 30 2017
prev sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Sunday, 30 April 2017 at 16:05:10 UTC, Igor wrote:

 I should also mention that compiling using DUB works. It only 
 doesn't work from VS.


Check your VisualD settings and make sure it has DMD path set up.
See under Tools>Options>Projects and solutions>Visual D Settings
Apr 30 2017
parent reply Igor <stojkovic.igor gmail.com> writes:
On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote:

 On Sunday, 30 April 2017 at 16:05:10 UTC, Igor wrote:

 I should also mention that compiling using DUB works. It only 
 doesn't work from VS.


 Check your VisualD settings and make sure it has DMD path set 
 up.
 See under Tools>Options>Projects and solutions>Visual D Settings


That was it. It didn't occur to me that this was the problem 
because I payed closed attention during VisualD installation and 
saw it properly recognized where DMD was installed but for some 
reason the path wasn't set in Options. Once I did set it, compile 
and build worked. Thanks evilrat!

So in conclusion it seems the problem is in VisualD installation 
which doesn't set the path properly even though it recognizes 
where DMD is installed. Hope the author takes a look at this 
problem so beginners wanting to try D don't give up on a problem 
like this.
May 01 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 01.05.2017 10:03, Igor wrote:

 On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote:

 On Sunday, 30 April 2017 at 16:05:10 UTC, Igor wrote:

 I should also mention that compiling using DUB works. It only doesn't
 work from VS.


 Check your VisualD settings and make sure it has DMD path set up.
 See under Tools>Options>Projects and solutions>Visual D Settings


 That was it. It didn't occur to me that this was the problem because I
 payed closed attention during VisualD installation and saw it properly
 recognized where DMD was installed but for some reason the path wasn't
 set in Options. Once I did set it, compile and build worked. Thanks
 evilrat!

 So in conclusion it seems the problem is in VisualD installation which
 doesn't set the path properly even though it recognizes where DMD is
 installed. Hope the author takes a look at this problem so beginners
 wanting to try D don't give up on a problem like this.


VS 2017 uses a "private" registry that the Visual D installer doesn't 
have access to. I'll change the registry location in the next release.

Please note that the next dmd installer will also detect VS2017 and 
setup directories correctly in sc.ini: 
https://github.com/dlang/installer/pull/227
May 01 2017
next sibling parent Igor <stojkovic.igor gmail.com> writes:
On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:

 VS 2017 uses a "private" registry that the Visual D installer 
 doesn't have access to. I'll change the registry location in 
 the next release.

 Please note that the next dmd installer will also detect VS2017 
 and setup directories correctly in sc.ini: 
 https://github.com/dlang/installer/pull/227


That is great news! Thanks for quick response.
May 01 2017
prev sibling next sibling parent reply Jolly James <j.j jmail.com> writes:
On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:

 Please note that the next dmd installer will also detect VS2017 
 and setup directories correctly in sc.ini: 
 https://github.com/dlang/installer/pull/227


I really like this philosophy:
"It does not work, a fix is available, but it won't be rolled out 
(for now). Who cares about those who cannot use the broken 
software?"
May 21 2017
next sibling parent evilrat <evilrat666 gmail.com> writes:
On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote:

 On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:

 Please note that the next dmd installer will also detect 
 VS2017 and setup directories correctly in sc.ini: 
 https://github.com/dlang/installer/pull/227


 I really like this philosophy:
 "It does not work, a fix is available, but it won't be rolled 
 out (for now). Who cares about those who cannot use the broken 
 software?"


Yeah great. However its actually working, one just have to set up 
paths manually. Just a little inconvenience.
May 21 2017
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote:

 On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:

 Please note that the next dmd installer will also detect 
 VS2017 and setup directories correctly in sc.ini: 
 https://github.com/dlang/installer/pull/227


 I really like this philosophy:
 "It does not work, a fix is available, but it won't be rolled 
 out (for now). Who cares about those who cannot use the broken 
 software?"


Please don't antagonize volunteer contributors who are actually 
creating and improving things. We have a release process for a 
reason, we can't ship every single change immediately. If you 
require a solution urgently, use a workaround or build it from 
source yourself.
May 22 2017
parent reply Jolly James <j.j jmail.com> writes:
On Monday, 22 May 2017 at 07:28:23 UTC, Vladimir Panteleev wrote:

 On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote:

 On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:

 Please note that the next dmd installer will also detect 
 VS2017 and setup directories correctly in sc.ini: 
 https://github.com/dlang/installer/pull/227


 I really like this philosophy:
 "It does not work, a fix is available, but it won't be rolled 
 out (for now). Who cares about those who cannot use the broken 
 software?"


 Please don't antagonize volunteer contributors who are actually 
 creating and improving things. We have a release process for a 
 reason, we can't ship every single change immediately. If you 
 require a solution urgently, use a workaround or build it from 
 source yourself.


My message was neither addressed directly to anybody of the 
volunteer contributors (I have a huge respect of them and their 
great work), nor to anyone at the D Foundation directly. I just 
wanted to critize the whole release cycle stuff itself.

I mean, if for any circumstance, e.g. like the VS2017 thing 
(which did not suddenly appear from one day to another anyway), 
the whole software cannot be used without larger fiddling (in 
this case: setting up NSIS + plugins), it seems quite strange to 
not simply update the installer, which would be a work for a few 
minutes - and after that everybody would be happy.
But to be honest, I don't think that this is a problem of D. More 
or less, this is something that appears everywhere in the world 
of open-source. Here it annoys and chases away users, in the 
corporate sector you could not do so, as this would cause the 
company's ruin.
May 22 2017
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 22 May 2017 at 21:08:02 UTC, Jolly James wrote:

 I mean, if for any circumstance, e.g. like the VS2017 thing 
 (which did not suddenly appear from one day to another anyway), 
 the whole software cannot be used without larger fiddling (in 
 this case: setting up NSIS + plugins), it seems quite strange 
 to not simply update the installer, which would be a work for a 
 few minutes - and after that everybody would be happy.
 But to be honest, I don't think that this is a problem of D. 
 More or less, this is something that appears everywhere in the 
 world of open-source. Here it annoys and chases away users, in 
 the corporate sector you could not do so, as this would cause 
 the company's ruin.


D's implementation (which is a part of the project as a whole) is 
cross-platform, we support several platforms other than Windows. 
Additionally, Visual Studio integration is an optional feature of 
the Windows version, and of course VS2017 is just one supported 
version of VS. The scope of the problem may seem larger to you 
because you are affected by it personally, however at any point 
in time there may be any number of fixes queued for release of 
similar relative importance. Making an urgent release for every 
such occurrence would be impractical, if not impossible given the 
necessary work involved with making each new release.

The difference between open-source and proprietary projects here 
is mainly that open-source projects do their development in the 
open. Generally, users usually are not made aware of the status 
of any particular fix or issue for proprietary projects up until 
the point that they appear in the changelog of a published 
release. Heck, most proprietary projects don't even have public 
bug trackers, or even forums for that matter.
May 22 2017
parent reply Jolly James <j.j jmail.com> writes:
On Monday, 22 May 2017 at 23:58:37 UTC, Vladimir Panteleev wrote:

 Additionally, Visual Studio integration is an optional feature 
 of the Windows version, and of course VS2017 is just one 
 supported version of VS.


Come one, let's be ones: If DMD has no x64 linker, VS integration 
is not a bit optional.


 The scope of the problem may seem larger to you because you are 
 affected by it personally, however at any point in time there 
 may be any number of fixes queued for release of similar 
 relative importance. Making an urgent release for every such 
 occurrence would be impractical, if not impossible given the 
 necessary work involved with making each new release.


So you are telling me "not working at all" is not worth releasing 
a fix? xD
May 23 2017
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 23 May 2017 at 23:11:30 UTC, Jolly James wrote:

 Come one, let's be ones: If DMD has no x64 linker, VS 
 integration is not a bit optional.


Unlike some other operating systems, 64-bit Windows versions can 
run 32-bit software just fine. If you require targeting Win64 (or 
the Microsoft C runtime), that is specific to your use case.

And, again, Visual Studio is not required if you want to target 
Win64 - only the necessary toolchain components (linker and C 
runtime), which you can also obtain from an SDK.


 So you are telling me "not working at all" is not worth 
 releasing a fix? xD


Again, everything should be already working. We are talking about 
a convenience feature that automatically sets up the D compiler's 
configuration file, nothing more. That's all there is to the 
"integration". You can trivially do the same thing by hand, or 
set up your environment accordingly - all in a fraction of the 
time it took you to write these pointless complaints on this 
forum.
May 23 2017
parent Jolly James <j.j jmail.com> writes:
On Wednesday, 24 May 2017 at 03:21:56 UTC, Vladimir Panteleev 
wrote:

 On Tuesday, 23 May 2017 at 23:11:30 UTC, Jolly James wrote:

 Come one, let's be ones: If DMD has no x64 linker, VS 
 integration is not a bit optional.


 Unlike some other operating systems, 64-bit Windows versions 
 can run 32-bit software just fine. If you require targeting 
 Win64 (or the Microsoft C runtime), that is specific to your 
 use case.


That's true. But when D's GC does not trigger early enough, my 
program runs out of memory (due to the 2 GB limit of 32 bit 
process), x64 solves this more or less. As a side note: I am 
talking about allocating huge arrays.



 And, again, Visual Studio is not required if you want to target 
 Win64 - only the necessary toolchain components (linker and C 
 runtime), which you can also obtain from an SDK.


 So you are telling me "not working at all" is not worth 
 releasing a fix? xD


 Again, everything should be already working. We are talking 
 about a convenience feature that automatically sets up the D 
 compiler's configuration file, nothing more. That's all there 
 is to the "integration". You can trivially do the same thing by 
 hand, or set up your environment accordingly - all in a 
 fraction of the time it took you to write these pointless 
 complaints on this forum.


I admit, you are right in some points. Nevertheless, have you 
ever tried letting a novice configuring this stuff? The 'sc.ini' 
is neither easy to read nor logic. In my particular case I am 
overchallenged by this task.
May 24 2017
prev sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Monday, 22 May 2017 at 21:08:02 UTC, Jolly James wrote:

 On Monday, 22 May 2017 at 07:28:23 UTC, Vladimir Panteleev 
 wrote:

 On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote:

 On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:

 Please note that the next dmd installer will also detect 
 VS2017 and setup directories correctly in sc.ini: 
 https://github.com/dlang/installer/pull/227


 I really like this philosophy:
 "It does not work, a fix is available, but it won't be rolled 
 out (for now). Who cares about those who cannot use the 
 broken software?"


 Please don't antagonize volunteer contributors who are 
 actually creating and improving things. We have a release 
 process for a reason, we can't ship every single change 
 immediately. If you require a solution urgently, use a 
 workaround or build it from source yourself.


 My message was neither addressed directly to anybody of the 
 volunteer contributors (I have a huge respect of them and their 
 great work), nor to anyone at the D Foundation directly. I just 
 wanted to critize the whole release cycle stuff itself.

 I mean, if for any circumstance, e.g. like the VS2017 thing 
 (which did not suddenly appear from one day to another anyway), 
 the whole software cannot be used without larger fiddling (in 
 this case: setting up NSIS + plugins), it seems quite strange 
 to not simply update the installer, which would be a work for a 
 few minutes - and after that everybody would be happy.
 But to be honest, I don't think that this is a problem of D. 
 More or less, this is something that appears everywhere in the 
 world of open-source. Here it annoys and chases away users, in 
 the corporate sector you could not do so, as this would cause 
 the company's ruin.


We already have nightly builds for all platforms supported by dmd 
[0]. We just need a nightly build of the installer, in addition 
to the 7zip archive for Windows. So I'd say we're already doing 
much better than 1-2 years ago.

[0]: http://nightlies.dlang.org/dmd-master-2017-05-23/
May 23 2017
prev sibling parent reply Jolly James <j.j jmail.com> writes:
On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:

 On 01.05.2017 10:03, Igor wrote:

 On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote:

 [...]


 That was it. It didn't occur to me that this was the problem 
 because I
 payed closed attention during VisualD installation and saw it 
 properly
 recognized where DMD was installed but for some reason the 
 path wasn't
 set in Options. Once I did set it, compile and build worked. 
 Thanks
 evilrat!

 So in conclusion it seems the problem is in VisualD 
 installation which
 doesn't set the path properly even though it recognizes where 
 DMD is
 installed. Hope the author takes a look at this problem so 
 beginners
 wanting to try D don't give up on a problem like this.


 VS 2017 uses a "private" registry that the Visual D installer 
 doesn't have access to. I'll change the registry location in 
 the next release.

 Please note that the next dmd installer will also detect VS2017 
 and setup directories correctly in sc.ini: 
 https://github.com/dlang/installer/pull/227


Today I saw that a new DMD version had been released. So I 
downloaded it (dmd-2.074.1.exe).

Unfortunately, the installer does *not* detect VS2017, instead it 
asks me to install VS2013 for x64 support.
Jun 04 2017
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, June 04, 2017 16:03:46 Jolly James via Digitalmars-d wrote:

 On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:

 On 01.05.2017 10:03, Igor wrote:

 On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote:

 [...]


 That was it. It didn't occur to me that this was the problem
 because I
 payed closed attention during VisualD installation and saw it
 properly
 recognized where DMD was installed but for some reason the
 path wasn't
 set in Options. Once I did set it, compile and build worked.
 Thanks
 evilrat!

 So in conclusion it seems the problem is in VisualD
 installation which
 doesn't set the path properly even though it recognizes where
 DMD is
 installed. Hope the author takes a look at this problem so
 beginners
 wanting to try D don't give up on a problem like this.


 VS 2017 uses a "private" registry that the Visual D installer
 doesn't have access to. I'll change the registry location in
 the next release.

 Please note that the next dmd installer will also detect VS2017
 and setup directories correctly in sc.ini:
 https://github.com/dlang/installer/pull/227


 Today I saw that a new DMD version had been released. So I
 downloaded it (dmd-2.074.1.exe).

 Unfortunately, the installer does *not* detect VS2017, instead it
 asks me to install VS2013 for x64 support.


That PR was merged into the master branch, not the stable branch, so the
updates to the installer will be in 2.075.0. Presumably, they either thought
that it was too large a change for a release that only has bugfixes, or they
just merged it into master, because that's the default, and they didn't
think about it.

- Jonathan M Davis
Jun 04 2017
parent Seb <seb wilzba.ch> writes:
On Sunday, 4 June 2017 at 23:45:34 UTC, Jonathan M Davis wrote:

 On Sunday, June 04, 2017 16:03:46 Jolly James via Digitalmars-d 
 wrote:

 On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:

 [...]


 Today I saw that a new DMD version had been released. So I
 downloaded it (dmd-2.074.1.exe).

 Unfortunately, the installer does *not* detect VS2017, instead 
 it asks me to install VS2013 for x64 support.


 That PR was merged into the master branch, not the stable 
 branch, so the updates to the installer will be in 2.075.0. 
 Presumably, they either thought that it was too large a change 
 for a release that only has bugfixes, or they just merged it 
 into master, because that's the default, and they didn't think 
 about it.

 - Jonathan M Davis


I strongly assume that it's the latter. It has simply been 
forgotten.
However, it's not difficult to cherry-pick it for `stable`:

https://github.com/dlang/installer/pull/228
Jun 04 2017
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 22 April 2017 at 02:22:56 UTC, NotSpooky wrote:

 I don't have Windows so I don't know if this has changed, but 
 last time I tried to install dmd there it asked to install VS 
 2013, I know some people that didn't want to install DMD 
 because VS is huge, now that the build tools are an option 
 maybe that's the one the installer should suggest (or maybe 
 even suggest both).


Realistically, anyone who does serious Windows development is 
likely going to have Visual Studio installed anyway. The build 
tools are fine for the rest, but anyone wanting to use Visual D 
will need VS. Since the installer offers to install Visual D, it 
only makes sense to offer to install VS. It might be good to 
offer a choice between the build tools and VS, or at the very 
least offer links to the build tools and more recent versions of 
VS to be installed manually.
Apr 21 2017