digitalmars.D - DMD VS2017 Support
- Jolly James (5/5) Apr 19 2017 DMD does not support VS2017. Therefore I cannot link x64
- Jolly James (3/3) Apr 19 2017 I cannot even fix it myself because DMD is looking for
- Mike B Johnson (7/10) Apr 19 2017 Edit your sc.ini in the dmd\windows\bin dir or use junctions to
- Meta (13/16) Apr 19 2017 Please ignore Mike's answer. Visual D is maintained by Rainers
- Jolly James (3/17) Apr 20 2017 What has the DMD compiler to do with a VS plugin that I am not
- Meta (6/8) Apr 20 2017 You said in your original post "DMD installer only offers to
- Mike Parker (2/10) Apr 20 2017 It actually does offer to install both VS 2013 and Visual D.
- Meta (2/13) Apr 20 2017 Wow, I did not know that. Seems a little excessive.
- Jolly James (4/18) Apr 20 2017 But anyway, that's how it is.
- Mike B Johnson (2/8) Apr 20 2017 Why should I be ignored? Specially when I'm right?
- Mike Parker (10/13) Apr 19 2017 You can install the MS Build Tools 2015. DMD will work with that.
- Mike Parker (3/13) Apr 19 2017 I should add that Mike's suggestion to edit sc.ini should do the
- Jolly James (2/7) Apr 20 2017 I'll give it a try, thanks to you and Mike J.! 👍🏻
- NotSpooky (5/7) Apr 21 2017 I'd be very nice if instead of offering to install VS, it offered
- Mike Parker (7/12) Apr 21 2017 There's no issue with compatibility. DMD is perfectly compatible
- NotSpooky (7/13) Apr 21 2017 Oh ok so it works with all of them.
- evilrat (11/25) Apr 21 2017 That was discussed so many times... DMD don't need VS itself but
- Mike Parker (3/8) Apr 21 2017 Yes, that is correct. But that comes with its own headaches.
- Igor (53/63) Apr 30 2017 I had a working VS 2015 with VisualD and DMD. Today I uninstalled
- Mike Parker (2/4) Apr 30 2017 Which paths did you set?
- Igor (12/17) Apr 30 2017 These are the ones I changed:
- John Chapman (12/31) Apr 30 2017 Here are mine, if it helps:
- Igor (3/4) Apr 30 2017 I tried but still the same problem. I also tried reinstalling
- Mike B Johnson (29/36) Apr 30 2017 You are going to have to figure it out. Visual Studio does some
- evilrat (3/5) Apr 30 2017 Check your VisualD settings and make sure it has DMD path set up.
- Igor (11/18) May 01 2017 That was it. It didn't occur to me that this was the problem
- Rainer Schuetze (6/23) May 01 2017 VS 2017 uses a "private" registry that the Visual D installer doesn't
- Igor (2/8) May 01 2017 That is great news! Thanks for quick response.
- Jolly James (5/8) May 21 2017 I really like this philosophy:
- evilrat (3/11) May 21 2017 Yeah great. However its actually working, one just have to set up
- Vladimir Panteleev (6/14) May 22 2017 Please don't antagonize volunteer contributors who are actually
- Jolly James (16/31) May 22 2017 My message was neither addressed directly to anybody of the
- Vladimir Panteleev (18/29) May 22 2017 D's implementation (which is a part of the project as a whole) is
- Jolly James (5/14) May 23 2017 Come one, let's be ones: If DMD has no x64 linker, VS integration
- Vladimir Panteleev (14/18) May 23 2017 Unlike some other operating systems, 64-bit Windows versions can
- Jolly James (10/29) May 24 2017 That's true. But when D's GC does not trigger early enough, my
- Petar Kirov [ZombineDev] (6/39) May 23 2017 We already have nightly builds for all platforms supported by dmd
- Jolly James (5/32) Jun 04 2017 Today I saw that a new DMD version had been released. So I
- Jonathan M Davis via Digitalmars-d (7/41) Jun 04 2017 That PR was merged into the master branch, not the stable branch, so the
- Seb (5/22) Jun 04 2017 I strongly assume that it's the latter. It has simply been
- Mike Parker (9/15) Apr 21 2017 Realistically, anyone who does serious Windows development is
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
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
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
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
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:What has the DMD compiler to do with a VS plugin that I am not using?[...]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 20 2017
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
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:It actually does offer to install both VS 2013 and Visual D.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
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:Wow, I did not know that. Seems a little excessive.On Thursday, 20 April 2017 at 14:29:28 UTC, Jolly James wrote:It actually does offer to install both VS 2013 and Visual D.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
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: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.On Thursday, 20 April 2017 at 14:44:54 UTC, Meta wrote:Wow, I did not know that. Seems a little excessive.On Thursday, 20 April 2017 at 14:29:28 UTC, Jolly James wrote:It actually does offer to install both VS 2013 and Visual D.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
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:Why should I be ignored? Specially when I'm right?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:
Apr 20 2017
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
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=48159I 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
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'll give it a try, thanks to you and Mike J.! 👍🏻[...]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 20 2017
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
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
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
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: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 buildsThere'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
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 buildsYes, that is correct. But that comes with its own headaches.
Apr 21 2017
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: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?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 buildsYes, that is correct. But that comes with its own headaches.
Apr 30 2017
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
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: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.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
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: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"On Sunday, 30 April 2017 at 14:56:44 UTC, Igor wrote: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.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
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
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: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.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
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
On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote:On Sunday, 30 April 2017 at 16:05:10 UTC, Igor 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.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
May 01 2017
On 01.05.2017 10:03, Igor wrote:On Monday, 1 May 2017 at 01:54:30 UTC, evilrat 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/227On Sunday, 30 April 2017 at 16:05:10 UTC, Igor 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.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
May 01 2017
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/227That is great news! Thanks for quick response.
May 01 2017
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/227I 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
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:Yeah great. However its actually working, one just have to set up paths manually. Just a little inconvenience.Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227I 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
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 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.Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227I 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 22 2017
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: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.On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: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.Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227I 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 22 2017
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
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
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? xDAgain, 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
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: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.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.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.So you are telling me "not working at all" is not worth releasing a fix? xDAgain, 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 24 2017
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: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/On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote: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.On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: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.Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227I 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 23 2017
On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:On 01.05.2017 10:03, Igor 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.On Monday, 1 May 2017 at 01:54:30 UTC, evilrat 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 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.
Jun 04 2017
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: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 DavisOn 01.05.2017 10:03, Igor 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.On Monday, 1 May 2017 at 01:54:30 UTC, evilrat 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 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.
Jun 04 2017
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: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/228On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: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[...]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
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