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