Re: DMD VS2017 Support
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
Re: DMD VS2017 Support
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
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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
Re: DMD VS2017 Support
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/
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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?"
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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"
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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?
Re: DMD VS2017 Support
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\testapp.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?
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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
Re: DMD VS2017 Support
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).
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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?
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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.! 👍🏻
Re: DMD VS2017 Support
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?
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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
Re: DMD VS2017 Support
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
Re: DMD VS2017 Support
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.
Re: DMD VS2017 Support
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".
