www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Help needed testing automatic win64 configuration

reply "Brad Anderson" <eco gnuk.net> writes:
There are some pending pull requests[1][2] to get automatic win64 
configuration during installation working.  I've prepared a dmd 
2.064-beta installer which includes these unmerged changes which 
you can download here:

http://gnuk.net/dmd-2.064-beta-new-sc.ini.exe


It downloads a slightly modified dmd2beta.zip from 
http://gnuk.net/dmd2beta.zip (my own server) because the 
installer requires some changes to sc.ini that the latest beta 
zip has not included (see 
http://d.puremagic.com/issues/show_bug.cgi?id=11266 ).

This installer also includes support for automatically 
downloading the Visual D installer and running it (another yet to 
be merged pull request[3]).

What I need is help testing it.  I only have the means to test on 
VC2010/SDK 7.0a at the moment. If you have any combination of 
VC2012 or VC2013 and Windows SDK 7.1, 8.0, or 8.1 it would help 
if you could try out this installer and test out building a 
simple 64-bit program (e.g., dmd -m64 helloworld.d) and reply 
here on whether or not it worked. Thanks.

1. https://github.com/D-Programming-Language/installer/pull/22
2. https://github.com/D-Programming-Language/dmd/pull/2667
3. https://github.com/D-Programming-Language/installer/pull/23
Oct 14 2013
next sibling parent reply "evilrat" <evilrat666 gmail.com> writes:
On Tuesday, 15 October 2013 at 02:17:39 UTC, Brad Anderson wrote:

 What I need is help testing it.  I only have the means to test 
 on VC2010/SDK 7.0a at the moment. If you have any combination 
 of VC2012 or VC2013 and Windows SDK 7.1, 8.0, or 8.1 it would 
 help if you could try out this installer and test out building 
 a simple 64-bit program (e.g., dmd -m64 helloworld.d) and reply 
 here on whether or not it worked. Thanks.



VS2012/SDK 7.1 gives following

C:\Users\Public\Documents\prog>dmd -m64 hello.d
Can't run 'C:\Program Files (x86)\Microsoft Visual Studio 
11.0\VC\bin\amd64\link
.exe', check PATH

my actual path to linker is C:\Program Files (x86)\Microsoft 
Visual Studio 11.0\VC\bin\x86_amd64 , after renaming the folder 
it requires by some reason mspdb11.dll, even after that it fails 
to link with over 1k missing symbols.
Oct 14 2013
next sibling parent reply "evilrat" <evilrat666 gmail.com> writes:
oops, sorry forgot to mentions that manually linking 
kernel32.lib/shell32.lib/user32.lib finally links and works. hope 
it helps
Oct 14 2013
parent "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 15 October 2013 at 04:23:38 UTC, evilrat wrote:

 oops, sorry forgot to mentions that manually linking 
 kernel32.lib/shell32.lib/user32.lib finally links and works. 
 hope it helps


Did you run the Visual Studio Command Prompt (2012) to do that?
Oct 14 2013
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 15 October 2013 at 04:20:06 UTC, evilrat wrote:

 On Tuesday, 15 October 2013 at 02:17:39 UTC, Brad Anderson 
 wrote:

 What I need is help testing it.  I only have the means to test 
 on VC2010/SDK 7.0a at the moment. If you have any combination 
 of VC2012 or VC2013 and Windows SDK 7.1, 8.0, or 8.1 it would 
 help if you could try out this installer and test out building 
 a simple 64-bit program (e.g., dmd -m64 helloworld.d) and 
 reply here on whether or not it worked. Thanks.



 VS2012/SDK 7.1 gives following

 C:\Users\Public\Documents\prog>dmd -m64 hello.d
 Can't run 'C:\Program Files (x86)\Microsoft Visual Studio 
 11.0\VC\bin\amd64\link
 .exe', check PATH


This version should fix that.
http://gnuk.net/dmd-2.064-beta-new-sc.ini-2.exe


 my actual path to linker is C:\Program Files (x86)\Microsoft 
 Visual Studio 11.0\VC\bin\x86_amd64 , after renaming the folder 
 it requires by some reason mspdb11.dll, even after that it 
 fails to link with over 1k missing symbols.


I don't know what to make of mspdb11.dll.  Anyone have any advice?
Oct 14 2013
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Tuesday, 15 October 2013 at 04:42:27 UTC, Brad Anderson wrote:

 This version should fix that.
 http://gnuk.net/dmd-2.064-beta-new-sc.ini-2.exe


ugh, no now it messed up lib and linker path in sc.ini, lib path 
was correct, only linker wrong, swap them.

 I don't know what to make of mspdb11.dll.  Anyone have any 
 advice?


i guess this is due running it without visual studio command 
prompt, but this can be fixed either by running it or utility 
script at VC/bin/x86_amd64/vcvarsx86_amd64.bat from console 
before using dmd.
Oct 14 2013
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 15 October 2013 at 05:07:19 UTC, evilrat wrote:

 On Tuesday, 15 October 2013 at 04:42:27 UTC, Brad Anderson 
 wrote:

 This version should fix that.
 http://gnuk.net/dmd-2.064-beta-new-sc.ini-2.exe


 ugh, no now it messed up lib and linker path in sc.ini, lib 
 path was correct, only linker wrong, swap them.

 I don't know what to make of mspdb11.dll.  Anyone have any 
 advice?


 i guess this is due running it without visual studio command 
 prompt, but this can be fixed either by running it or utility 
 script at VC/bin/x86_amd64/vcvarsx86_amd64.bat from console 
 before using dmd.


What's the path to mspdb11.dll?
Oct 14 2013
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Tuesday, 15 October 2013 at 05:31:51 UTC, Brad Anderson wrote:

 On Tuesday, 15 October 2013 at 05:07:19 UTC, evilrat wrote:

 On Tuesday, 15 October 2013 at 04:42:27 UTC, Brad Anderson 
 wrote:

 This version should fix that.
 http://gnuk.net/dmd-2.064-beta-new-sc.ini-2.exe


 ugh, no now it messed up lib and linker path in sc.ini, lib 
 path was correct, only linker wrong, swap them.

 I don't know what to make of mspdb11.dll.  Anyone have any 
 advice?


 i guess this is due running it without visual studio command 
 prompt, but this can be fixed either by running it or utility 
 script at VC/bin/x86_amd64/vcvarsx86_amd64.bat from console 
 before using dmd.


 What's the path to mspdb11.dll?


Microsoft Visual Studio 11.0\Common7\IDE\mspdb110.dll

but don't add it manually, it should be added with VS prompt or 
that cvars script.
Oct 14 2013
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 15 October 2013 at 05:48:07 UTC, evilrat wrote:

 On Tuesday, 15 October 2013 at 05:31:51 UTC, Brad Anderson 
 wrote:

 On Tuesday, 15 October 2013 at 05:07:19 UTC, evilrat wrote:

 On Tuesday, 15 October 2013 at 04:42:27 UTC, Brad Anderson 
 wrote:

 This version should fix that.
 http://gnuk.net/dmd-2.064-beta-new-sc.ini-2.exe


 ugh, no now it messed up lib and linker path in sc.ini, lib 
 path was correct, only linker wrong, swap them.

 I don't know what to make of mspdb11.dll.  Anyone have any 
 advice?


 i guess this is due running it without visual studio command 
 prompt, but this can be fixed either by running it or utility 
 script at VC/bin/x86_amd64/vcvarsx86_amd64.bat from console 
 before using dmd.


 What's the path to mspdb11.dll?


 Microsoft Visual Studio 11.0\Common7\IDE\mspdb110.dll

 but don't add it manually, it should be added with VS prompt or 
 that cvars script.


I'm at a loss for how I would anyway.  My only option might be to 
add execution of vcvars to the D2 Command Prompt shortcut I make. 
  I'm going to sleep on this and think about it some more.
Oct 14 2013
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Tuesday, 15 October 2013 at 06:24:28 UTC, Brad Anderson wrote:

 I'm at a loss for how I would anyway.  My only option might be 
 to add execution of vcvars to the D2 Command Prompt shortcut I 
 make.
  I'm going to sleep on this and think about it some more.


ah ok, i've never used dmd prompt myself anyway, so i would 
prefer if there will be script at dmd path which calls that 
cvars, because i really only use win+r & cmd, with or without 
dub, or visuald.
Oct 14 2013
parent "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 15 October 2013 at 06:37:52 UTC, evilrat wrote:

 On Tuesday, 15 October 2013 at 06:24:28 UTC, Brad Anderson 
 wrote:

 I'm at a loss for how I would anyway.  My only option might be 
 to add execution of vcvars to the D2 Command Prompt shortcut I 
 make.
 I'm going to sleep on this and think about it some more.


 ah ok, i've never used dmd prompt myself anyway, so i would 
 prefer if there will be script at dmd path which calls that 
 cvars, because i really only use win+r & cmd, with or without 
 dub, or visuald.


Looks like I can probably just stick a:

PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE

in there according to an sc.ini Rainer posted.  I'll check this 
all out tomorrow.
Oct 14 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 15 October 2013 at 02:17:39 UTC, Brad Anderson wrote:

 There are some pending pull requests[1][2] to get automatic 
 win64 configuration during installation working.  I've prepared 
 a dmd 2.064-beta installer which includes these unmerged 
 changes which you can download here:

 http://gnuk.net/dmd-2.064-beta-new-sc.ini.exe


Updated version (removed old one to avoid confusion):
http://gnuk.net/dmd-2.064-beta-new-sc.ini-2.exe
Oct 14 2013
prev sibling next sibling parent reply "dnewbie" <run3 myopera.com> writes:
VS 2010 Express/Windows SDK 7.0:

dmd -m64 hello.d
Can't run 'c:\Program Files (x86)\Microsoft Visual Studio 
10.0\VC\bin\amd64\link.exe', check PATH

with dmd-2.064-beta-new-sc.ini-2.exe
Oct 14 2013
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 15 October 2013 at 06:38:30 UTC, dnewbie wrote:

 VS 2010 Express/Windows SDK 7.0:

 dmd -m64 hello.d
 Can't run 'c:\Program Files (x86)\Microsoft Visual Studio 
 10.0\VC\bin\amd64\link.exe', check PATH

 with dmd-2.064-beta-new-sc.ini-2.exe


I believe you need the 7.1 SDK.  7.0 does not come with the 
64-bit toolset.  I'm not certain about the paths in an 
Express/7.1 setup.

If you can give me the paths to:

1. 64-bit link.exe
2. 64-bit C Runtime libraries (in MSVC this is 
%VCINSTALLDIR%lib\amd64 but I'm not sure if that comes with 
Express or with the 7.1 SDK and is located somewhere in SDK's 
directory structure instead).

I might be able to this working.
Oct 15 2013
next sibling parent reply Manu <turkeyman gmail.com> writes:
I just tried your '-3' version. It has problems.

1: VisualD installer still asks where you installed DMD; it should be able
to know this since it's being invoked by the DMD installer. I think that
should be fixed.
2: gcstub64.obj and phobos64.lib are still in D/dmd2/windows/lib. They
should be moved to lib64/
3: sc.ini contains: LIB="% P%\..\lib64";"% P%\..\lib"   <- why is '../lib/'
still present in [Environment64]? That should be removed, it can only lead
to erroneous attempts to link the OMF libs. Rather have a "can't find lib"
error, than a weird lib format error that most programmers won't understand.
4: It fails to find the Microsoft libs. Here is the relevant parts of my
sc.ini as installed by the installer:

LIB="% P%\..\lib64";"% P%\..\lib"

;;;; search path for C Runtime libraries
; the following lib path works with VS2008, VS2010, VS2012, VS2013
; prepending because 32-bit OMF versions can cause link.exe to fail
LIB="C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64";%LIB%

;;;; search path for Platform libraries
; the following lib path works with Windows SDK 6.x and 7.x
LIB="C:\Program Files (x86)\Windows Kits\8.0\lib\winv6.3\um\x64";%LIB%

; the following lib path works with Windows SDK 8.0 and 8.1
LIB="%WindowsSdkDir%Lib\win8\um\x64";%LIB%


I have VS2010 and VS2012 installed on a Win8 machine. I have libs in these
locations:

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64  <- this one
seems to be unknown to the installer. These libs should be used in
conjunction with VS2010.
C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64  <- the installer
refers to %WindowsSdkDir%, which is not present on my system. Use the
absolute path instead? These libs are to use used in conjunction with
VS2012.
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64  <-
runtime libs, how to pick which version? Prompt during installation?
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64  <-
runtime libs, how to pick which version? Prompt during installation?

I should note that I think VisualD needs to do some work here too. VisualD
should override the linker and lib paths, since it has more information.
Ie, how does cmdline DMD choose which linker/runtime libs to use? Perhaps a
prompt during installation? Choose the newest (appears to be the current
behaviour).
Whereas VisualD will be running inside of an instance of either VS2010 or
VS2012 (I use both, this is very common practise) on my machine, and it
should configure the linker and lib paths appropriately for the version of
VisualStudio currently in use when building, otherwise there will be link
troubles against C/C++ libraries also being built in the same solution
(yes, it's common to have C/C++ and D in the same solution).

For clarity, on my system, when using the VS2010 compiler, it should use
these lib paths:
  runtime libs: C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\lib\amd64
  windows libs: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64
   <- AFAIK, Microsoft SDKs is the old location, installed with VS2010 and
earlier.

When using the VS2012 compiler, it should use these paths:
  runtime libs: C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\lib\amd64
  windows libs: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64
 <- Windows Kits is the new location, by versions > VS2010 (AFAIK).


The default installation of DMD using your new installer fails to link on
my machine because %WindowsSdkDir% is not defined on my system, and since
the 32bit dmd lib path is still present, it tries to link the OMF libs, and
complains a lot.

Elsewhere in the file, you detect VS2010LINKCMD, VS2013LINKCMD, etc. Why
not also have a matching suite of VS2010LIBPATH="C:\Program Files
(x86)\Microsoft Visual Studio 10.0\VC\lib\amd64" and friends, and refer to
them down the bottom as LIB=%VS2010LIBPATH%;%LIB%, along
with LINKCMD64=%VS2010LINKCMD%.


at the bottom, assign the actual variables used by DMD to the version
selected by the user when prompted during installation. The result of this
is that sc.ini will be very easy to read and understand, and if the user
later wants to switch to another VS version, it'll be obvious to change the


My primary VS environment is VS2010, which is going to be wrong if the
installer uses a 'prefer newest version' strategy.

Another question, why use LINKCMD64? Shouldn't it just be LINKCMD, since
it's under the [Environment64] block? You're not using LIB64, or any others
like that.

On 16 October 2013 11:15, Brad Anderson <eco gnuk.net> wrote:


 On Tuesday, 15 October 2013 at 06:38:30 UTC, dnewbie wrote:


 VS 2010 Express/Windows SDK 7.0:

 dmd -m64 hello.d
 Can't run 'c:\Program Files (x86)\Microsoft Visual Studio
 10.0\VC\bin\amd64\link.exe', check PATH

 with dmd-2.064-beta-new-sc.ini-2.**exe


 I believe you need the 7.1 SDK.  7.0 does not come with the 64-bit
 toolset.  I'm not certain about the paths in an Express/7.1 setup.

 If you can give me the paths to:

 1. 64-bit link.exe
 2. 64-bit C Runtime libraries (in MSVC this is %VCINSTALLDIR%lib\amd64 but
 I'm not sure if that comes with Express or with the 7.1 SDK and is located
 somewhere in SDK's directory structure instead).

 I might be able to this working.
Oct 15 2013
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 16.10.2013 04:45, Manu wrote:

 I just tried your '-3' version. It has problems.

 1: VisualD installer still asks where you installed DMD; it should be
 able to know this since it's being invoked by the DMD installer.. I
 think that should be fixed.


I have not yet updated the Visual D installer to pick up the setting. 
Will do.


 2: gcstub64.obj and phobos64.lib are still in D/dmd2/windows/lib. They
 should be moved to lib64/


We are trying to talk Walter into doing this but it seems there are 
topics that fail to gain traction.


 3: sc.ini contains: LIB="% P%\...\lib64";"% P%\..\lib"   <- why is
 '../lib/' still present in [Environment64]? That should be removed, it
 can only lead to erroneous attempts to link the OMF libs. Rather have a
 "can't find lib" error, than a weird lib format error that most
 programmers won't understand.


Sure, that should be done when the 64 bit files are moved to their own 
folder.


 4: It fails to find the Microsoft libs. Here is the relevant parts of my
 sc.ini as installed by the installer:

 LIB="% P%\..\lib64";"% P%\..\lib"

 ;;;; search path for C Runtime libraries
 ; the following lib path works with VS2008, VS2010, VS2012, VS2013
 ; prepending because 32-bit OMF versions can cause link.exe to fail
 LIB="C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64";%LIB%

 ;;;; search path for Platform libraries
 ; the following lib path works with Windows SDK 6.x and 7.x
 LIB="C:\Program Files (x86)\Windows Kits\8.0\lib\winv6.3\um\x64";%LIB%

 ; the following lib path works with Windows SDK 8.0 and 8.1
 LIB="%WindowsSdkDir%Lib\win8\um\x64";%LIB%


 I have VS2010 and VS2012 installed on a Win8 machine. I have libs in
 these locations:

 C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64  <- this one
 seems to be unknown to the installer. These libs should be used in
 conjunction with VS2010.
 C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64  <- the
 installer refers to %WindowsSdkDir%, which is not present on my system.
 Use the absolute path instead? These libs are to use used in conjunction
 with VS2012.
 C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64  <-
 runtime libs, how to pick which version? Prompt during installation?
 C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64  <-
 runtime libs, how to pick which version? Prompt during installation?

 I should note that I think VisualD needs to do some work here too.
 VisualD should override the linker and lib paths, since it has more
 information.
 Ie, how does cmdline DMD choose which linker/runtime libs to use?
 Perhaps a prompt during installation? Choose the newest (appears to be
 the current behaviour).
 Whereas VisualD will be running inside of an instance of either VS2010
 or VS2012 (I use both, this is very common practise) on my machine, and
 it should configure the linker and lib paths appropriately for the
 version of VisualStudio currently in use when building, otherwise there
 will be link troubles against C/C++ libraries also being built in the
 same solution (yes, it's common to have C/C++ and D in the same solution).


The installer tries to pick the latest version of both VS and SDK 
installations. I see there is a problem when selecting a different C 
runtime than what your C/C++ code is assuming. Is the Windows-SDK a 
problem, too? The files used are just import libraries, so the latest 
should be fine as long as you don't need linker errors when you build an 
application to be run on XP but are calling Win8 only functions.


 For clarity, on my system, when using the VS2010 compiler, it should use
 these lib paths:
    runtime libs: C:\Program Files (x86)\Microsoft Visual Studio
 10.0\VC\lib\amd64
    windows libs: C:\Program Files (x86)\Microsoft
 SDKs\Windows\v7.0A\Lib\x64    <- AFAIK, Microsoft SDKs is the old
 location, installed with VS2010 and earlier.

 When using the VS2012 compiler, it should use these paths:
    runtime libs: C:\Program Files (x86)\Microsoft Visual Studio
 11.0\VC\lib\amd64
    windows libs: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64
     <- Windows Kits is the new location, by versions > VS2010 (AFAIK).


 The default installation of DMD using your new installer fails to link
 on my machine because %WindowsSdkDir% is not defined on my system, and
 since the 32bit dmd lib path is still present, it tries to link the OMF
 libs, and complains a lot.


It seems the installer failed to replace two occurences of 
%WindowsSdkDir%. WindowsSdkDir is set by batch files vsvars32.bat and 
friends. I see conflicting goals here:

1. the installer expands variables WindowsSdkDir and VCINSTALLDIR in 
sc.ini to work without running vsvars32.bat. It has to make decisions on 
what versions to pick up.

2. when running dmd by Visual D you want to select settings according to 
the current Visual Studio, which means it needs the unexpanded variables.

The current option to allow both is to not run the linker through dmd, 
but invoke it "manually".


 Elsewhere in the file, you detect VS2010LINKCMD, VS2013LINKCMD, etc. Why
 not also have a matching suite of VS2010LIBPATH="C:\Program Files
 (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64" and friends, and refer
 to them down the bottom as LIB=%VS2010LIBPATH%;%LIB%, along
 with LINKCMD64=%VS2010LINKCMD%.


 then at the bottom, assign the actual variables used by DMD to the
 version selected by the user when prompted during installation. The
 result of this is that sc.ini will be very easy to read and understand,
 and if the user later wants to switch to another VS version, it'll be


 My primary VS environment is VS2010, which is going to be wrong if the
 installer uses a 'prefer newest version' strategy.




 Another question, why use LINKCMD64? Shouldn't it just be LINKCMD, since
 it's under the [Environment64] block? You're not using LIB64, or any
 others like that.


There is a already pull request to change this: 
https://github.com/D-Programming-Language/dmd/pull/2667
Oct 16 2013
parent reply Manu <turkeyman gmail.com> writes:
On 16 October 2013 17:16, Rainer Schuetze <r.sagitario gmx.de> wrote:


 On 16.10.2013 04:45, Manu wrote:


  2: gcstub64.obj and phobos64.lib are still in D/dmd2/windows/lib. They
 should be moved to lib64/


 We are trying to talk Walter into doing this but it seems there are topics
 that fail to gain traction.


Cool, well if it get's there, I should add that it would be nice to lose
the '64' suffix too. No reason for them to have different filenames if
they're in lib64/. Just creates extra annoying logic in build scripts.


 4: It fails to find the Microsoft libs. Here is the relevant parts of my

 sc.ini as installed by the installer:

 LIB="% P%\..\lib64";"% P%\..\**lib"

 ;;;; search path for C Runtime libraries
 ; the following lib path works with VS2008, VS2010, VS2012, VS2013
 ; prepending because 32-bit OMF versions can cause link.exe to fail
 LIB="C:\Program Files (x86)\Microsoft Visual Studio
 11.0\VC\lib\amd64";%LIB%

 ;;;; search path for Platform libraries
 ; the following lib path works with Windows SDK 6.x and 7.x
 LIB="C:\Program Files (x86)\Windows Kits\8.0\lib\winv6.3\um\x64";%**LIB%

 ; the following lib path works with Windows SDK 8.0 and 8.1
 LIB="%WindowsSdkDir%Lib\win8\**um\x64";%LIB%


 I have VS2010 and VS2012 installed on a Win8 machine. I have libs in
 these locations:

 C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64  <- this one
 seems to be unknown to the installer. These libs should be used in
 conjunction with VS2010.
 C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64  <- the
 installer refers to %WindowsSdkDir%, which is not present on my system.
 Use the absolute path instead? These libs are to use used in conjunction
 with VS2012.
 C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64  <-
 runtime libs, how to pick which version? Prompt during installation?
 C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64  <-
 runtime libs, how to pick which version? Prompt during installation?

 I should note that I think VisualD needs to do some work here too.
 VisualD should override the linker and lib paths, since it has more
 information.
 Ie, how does cmdline DMD choose which linker/runtime libs to use?
 Perhaps a prompt during installation? Choose the newest (appears to be
 the current behaviour).
 Whereas VisualD will be running inside of an instance of either VS2010
 or VS2012 (I use both, this is very common practise) on my machine, and
 it should configure the linker and lib paths appropriately for the
 version of VisualStudio currently in use when building, otherwise there
 will be link troubles against C/C++ libraries also being built in the
 same solution (yes, it's common to have C/C++ and D in the same solution).


 The installer tries to pick the latest version of both VS and SDK
 installations. I see there is a problem when selecting a different C
 runtime than what your C/C++ code is assuming. Is the Windows-SDK a
 problem, too? The files used are just import libraries, so the latest
 should be fine as long as you don't need linker errors when you build an
 application to be run on XP but are calling Win8 only functions.


You're probably right about the system library path. I haven't had any
issues of this sort, but I just tend to be behave conservatively when it
comes to this sort of thing. There are so many unexpected ways that linking
goes wrong in the windows ecosystem.

The runtime libraries are definitely a problem. The 'select most recent'
policy is incorrect in my case. VS2010 is the environment I do 99% of my
work, and I have experienced issued when C and D projects are together in
the same solution.
I'm not sure what the best solution is here. My feeling is that a prompt in
the installer to offer which version to hook up as the default, and VisualD
overriding these variables somehow.
There's no way for VisualD to override this variable when invoking the
compiler? You mention below that it would only be possible with separate
linkage, why is that?


For clarity, on my system, when using the VS2010 compiler, it should use

 these lib paths:
    runtime libs: C:\Program Files (x86)\Microsoft Visual Studio

 10.0\VC\lib\amd64
    windows libs: C:\Program Files (x86)\Microsoft
 SDKs\Windows\v7.0A\Lib\x64    <- AFAIK, Microsoft SDKs is the old
 location, installed with VS2010 and earlier.

 When using the VS2012 compiler, it should use these paths:
    runtime libs: C:\Program Files (x86)\Microsoft Visual Studio

 11.0\VC\lib\amd64
    windows libs: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64
     <- Windows Kits is the new location, by versions > VS2010 (AFAIK).


 The default installation of DMD using your new installer fails to link
 on my machine because %WindowsSdkDir% is not defined on my system, and
 since the 32bit dmd lib path is still present, it tries to link the OMF
 libs, and complains a lot.


 It seems the installer failed to replace two occurences of
 %WindowsSdkDir%. WindowsSdkDir is set by batch files vsvars32.bat and
 friends. I see conflicting goals here:

 1. the installer expands variables WindowsSdkDir and VCINSTALLDIR in
 sc.ini to work without running vsvars32.bat. It has to make decisions on
 what versions to pick up.

 2. when running dmd by Visual D you want to select settings according to
 the current Visual Studio, which means it needs the unexpanded variables.

 The current option to allow both is to not run the linker through dmd, but
 invoke it "manually".


What do you mean by 'manually' exactly?
Is there anything that can be done in VisualD to override these variables
when invoking the compiler?


There's one other detail that I forgot in my prior email; I think it would
be really handy to include the DirectX lib path by default.
It's a very standard MS lib package, and anyone who does multimedia
development will surely have it on their system, and require it to be
hooked up.
My DX libs are here: C:\Program Files (x86)\Microsoft DirectX SDK (June
2010)\Lib\x64
It seems I have an environment variable: DXSDK_DIR=C:\Program Files
(x86)\Microsoft DirectX SDK (June 2010)\
It also seems to register a presence in the registry at:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DirectX\Microsoft DirectX
SDK (June 2010)\InstallPath

I usually have more faith in the registry, but the env variable is surely
going to be present on everyone's machine.
Oct 16 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 16.10.2013 13:13, Manu wrote:

 On 16 October 2013 17:16, Rainer Schuetze <r.sagitario gmx.de
     We are trying to talk Walter into doing this but it seems there are
     topics that fail to gain traction.


 Cool, well if it get's there, I should add that it would be nice to lose
 the '64' suffix too. No reason for them to have different filenames if
 they're in lib64/. Just creates extra annoying logic in build scripts.


I agree.

[...]

     The installer tries to pick the latest version of both VS and SDK
     installations. I see there is a problem when selecting a different C
     runtime than what your C/C++ code is assuming. Is the Windows-SDK a
     problem, too? The files used are just import libraries, so the
     latest should be fine as long as you don't need linker errors when
     you build an application to be run on XP but are calling Win8 only
     functions.


 You're probably right about the system library path. I haven't had any
 issues of this sort, but I just tend to be behave conservatively when it
 comes to this sort of thing. There are so many unexpected ways that
 linking goes wrong in the windows ecosystem.

 The runtime libraries are definitely a problem. The 'select most recent'
 policy is incorrect in my case. VS2010 is the environment I do 99% of my
 work, and I have experienced issued when C and D projects are together
 in the same solution.
 I'm not sure what the best solution is here. My feeling is that a prompt
 in the installer to offer which version to hook up as the default, and
 VisualD overriding these variables somehow.
 There's no way for VisualD to override this variable when invoking the
 compiler? You mention below that it would only be possible with separate
 linkage, why is that?


[...]

     It seems the installer failed to replace two occurences of
     %WindowsSdkDir%. WindowsSdkDir is set by batch files vsvars32.bat
     and friends. I see conflicting goals here:

     1. the installer expands variables WindowsSdkDir and VCINSTALLDIR in
     sc.ini to work without running vsvars32.bat. It has to make
     decisions on what versions to pick up.

     2. when running dmd by Visual D you want to select settings
     according to the current Visual Studio, which means it needs the
     unexpanded variables.

     The current option to allow both is to not run the linker through
     dmd, but invoke it "manually".


 What do you mean by 'manually' exactly?
 Is there anything that can be done in VisualD to override these
 variables when invoking the compiler?


By "manually" I mean that the linker is not run through dmd, but is 
called directly from the batch generated by Visual D. This means, Visual 
D has to extract all the settings from sc.ini and rebuild the command 
line that dmd would generate. In addition, it needs to know which 
settings have to be replaced and which have been set deliberately by the 
user.


 There's one other detail that I forgot in my prior email; I think it
 would be really handy to include the DirectX lib path by default.
 It's a very standard MS lib package, and anyone who does multimedia
 development will surely have it on their system, and require it to be
 hooked up.
 My DX libs are here: C:\Program Files (x86)\Microsoft DirectX SDK (June
 2010)\Lib\x64
 It seems I have an environment variable: DXSDK_DIR=C:\Program Files
 (x86)\Microsoft DirectX SDK (June 2010)\
 It also seems to register a presence in the registry at:
 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DirectX\Microsoft
 DirectX SDK (June 2010)\InstallPath

 I usually have more faith in the registry, but the env variable is
 surely going to be present on everyone's machine.


I'm not sure we should add too many special cases, everybody has his own 
set of favorite libraries (I haven't touched DirectX for more than 10 
years). Considering that you probably have to make your own imports for 
the respective declarations, I think it is ok to add an appropriate 
library path to your project aswell.

It seems the DX-SDK does not end up in the LIB environment variable for 
the VS command prompt aswell, though I see it added in the Visual Studio 
settings.
Oct 17 2013
parent reply Manu <turkeyman gmail.com> writes:
On 17 October 2013 17:08, Rainer Schuetze <r.sagitario gmx.de> wrote:


 On 16.10.2013 13:13, Manu wrote:


     It seems the installer failed to replace two occurences of
     %WindowsSdkDir%. WindowsSdkDir is set by batch files vsvars32.bat
     and friends. I see conflicting goals here:

     1. the installer expands variables WindowsSdkDir and VCINSTALLDIR in
     sc.ini to work without running vsvars32.bat. It has to make
     decisions on what versions to pick up.

     2. when running dmd by Visual D you want to select settings
     according to the current Visual Studio, which means it needs the
     unexpanded variables.

     The current option to allow both is to not run the linker through
     dmd, but invoke it "manually".


 What do you mean by 'manually' exactly?
 Is there anything that can be done in VisualD to override these
 variables when invoking the compiler?


 By "manually" I mean that the linker is not run through dmd, but is called
 directly from the batch generated by Visual D. This means, Visual D has to
 extract all the settings from sc.ini and rebuild the command line that dmd
 would generate. In addition, it needs to know which settings have to be
 replaced and which have been set deliberately by the user.


Hmmm, I tend to think that sc.ini should be ignored/overridden entirely
under VisualD.
Visual Studio has all its own places to configure paths and options.

Anyone who runs more than one version of Visual Studio has to micro-manage
sc.ini, which is really annoying.
As a VisualD user, I expect to be able to access all settings and paths in
Visual Studio, and they should be relevant for the version of Visual Studio
in use.

At least that's my take on it, from an end-user perspective.


On a side note, Visual Studio tends to maintain it's default settings in
property sheets (you can access the x64 defaults under
Microsoft.Cpp.x64.user under the Property Manager). I wonder if VisualD
should also store defaults in the same place, but then I noticed that
VisualD project's don't seem to have any presence in the Property
Manager... I guess it's a special project type, and therefore subvert's
MSBuild? I don't really know how all that stuff fits together.


You know, thinking on it, it's kinda strange in a sense that D should have
completely distinct library paths at all. It might be useful in VisualD to
add all the C/C++ x64 library paths as standard link paths aswell.
Surely it's reasonable as a Visual Studio end-user to assume that any libs
available to C/C++ should also be available to D too? These are 'system
libs' after all. At least, they've been registered with VS as if they are.


There's one other detail that I forgot in my prior email; I think it

 would be really handy to include the DirectX lib path by default.
 It's a very standard MS lib package, and anyone who does multimedia
 development will surely have it on their system, and require it to be
 hooked up.
 My DX libs are here: C:\Program Files (x86)\Microsoft DirectX SDK (June

 2010)\Lib\x64
 It seems I have an environment variable: DXSDK_DIR=C:\Program Files
 (x86)\Microsoft DirectX SDK (June 2010)\
 It also seems to register a presence in the registry at:
 HKEY_LOCAL_MACHINE\SOFTWARE\**Wow6432Node\Microsoft\DirectX\**Microsoft
 DirectX SDK (June 2010)\InstallPath

 I usually have more faith in the registry, but the env variable is
 surely going to be present on everyone's machine.


 I'm not sure we should add too many special cases, everybody has his own
 set of favorite libraries (I haven't touched DirectX for more than 10
 years). Considering that you probably have to make your own imports for the
 respective declarations, I think it is ok to add an appropriate library
 path to your project aswell.

 It seems the DX-SDK does not end up in the LIB environment variable for
 the VS command prompt aswell, though I see it added in the Visual Studio
 settings.


I only suggest the DXSDK lib in particular for a few reasons:
 1. It's a really standard Microsoft lib, not just some 3rd party thing.
 2. Being a Microsoft lib, it integrates into Visual Studio automatically
when installed, and it's necessary to do basically any multimedia in
windows.
 3. It's been integrated into the Windows 8 SDK from VS2012 and on (that's
why the stand-alone package is quite old), but for the sake of 'it just
works', for prior versions of Visual Studio (which we do support), the path
needs to be added.

Ie, there's a risk of VS2012 users saying "well it works for me!", but the
VS2010 users complaining that it doesn't seem to work for them, and then
scratching heads why it works for some but not others.
Oct 17 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 17.10.2013 10:41, Manu wrote:

 On 17 October 2013 17:08, Rainer Schuetze <r.sagitario gmx.de
 <mailto:r.sagitario gmx.de>> wrote:



     On 16.10.2013 13:13, Manu wrote:


              It seems the installer failed to replace two occurences of
              %WindowsSdkDir%. WindowsSdkDir is set by batch files
         vsvars32..bat
              and friends. I see conflicting goals here:

              1. the installer expands variables WindowsSdkDir and
         VCINSTALLDIR in
              sc.ini to work without running vsvars32.bat. It has to make
              decisions on what versions to pick up.

              2. when running dmd by Visual D you want to select settings
              according to the current Visual Studio, which means it
         needs the
              unexpanded variables.

              The current option to allow both is to not run the linker
         through
              dmd, but invoke it "manually".


         What do you mean by 'manually' exactly?
         Is there anything that can be done in VisualD to override these
         variables when invoking the compiler?


     By "manually" I mean that the linker is not run through dmd, but is
     called directly from the batch generated by Visual D. This means,
     Visual D has to extract all the settings from sc.ini and rebuild the
     command line that dmd would generate. In addition, it needs to know
     which settings have to be replaced and which have been set
     deliberately by the user.


 Hmmm, I tend to think that sc.ini should be ignored/overridden entirely
 under VisualD.
 Visual Studio has all its own places to configure paths and options.

 Anyone who runs more than one version of Visual Studio has to
 micro-manage sc.ini, which is really annoying.
 As a VisualD user, I expect to be able to access all settings and paths
 in Visual Studio, and they should be relevant for the version of Visual
 Studio in use.

 At least that's my take on it, from an end-user perspective.


Makes sense, though I'm unsure how to stop dmd from interpreting sc.ini. 
Adding an empty sc.ini into the project folder could work, but is a bit 
ugly.


 On a side note, Visual Studio tends to maintain it's default settings in
 property sheets (you can access the x64 defaults under
 Microsoft.Cpp.x64.user under the Property Manager). I wonder if VisualD
 should also store defaults in the same place, but then I noticed that
 VisualD project's don't seem to have any presence in the Property
 Manager... I guess it's a special project type, and therefore subvert's
 MSBuild? I don't really know how all that stuff fits together.


When I started work on Visual D, VS2008 was the current version and it 

to build on top of msbuild.

Even with VS2010, I don't like msbuild. I think msbuild has good 
dependency handling, see the Intel Compiler integration which is 
horrible. My impression is that MS subverts msbuild for C++ to make it 
acceptable.


 You know, thinking on it, it's kinda strange in a sense that D should
 have completely distinct library paths at all. It might be useful in
 VisualD to add all the C/C++ x64 library paths as standard link paths
 aswell.
 Surely it's reasonable as a Visual Studio end-user to assume that any
 libs available to C/C++ should also be available to D too? These are
 'system libs' after all. At least, they've been registered with VS as if
 they are.


I tend to agree. I'll see if I can find the C++ settings somewhere, so I 
can add a switch to add the library paths automatically.

I think we'll need different global settings for Win32 and Win64, too.


         There's one other detail that I forgot in my prior email; I think it
         would be really handy to include the DirectX lib path by default.
         It's a very standard MS lib package, and anyone who does multimedia
         development will surely have it on their system, and require it
         to be
         hooked up.
         My DX libs are here: C:\Program Files (x86)\Microsoft DirectX
         SDK (June

         2010)\Lib\x64
         It seems I have an environment variable: DXSDK_DIR=C:\Program Files
         (x86)\Microsoft DirectX SDK (June 2010)\
         It also seems to register a presence in the registry at:
         HKEY_LOCAL_MACHINE\SOFTWARE\__Wow6432Node\Microsoft\DirectX\__Microsoft
         DirectX SDK (June 2010)\InstallPath

         I usually have more faith in the registry, but the env variable is
         surely going to be present on everyone's machine.


     I'm not sure we should add too many special cases, everybody has his
     own set of favorite libraries (I haven't touched DirectX for more
     than 10 years). Considering that you probably have to make your own
     imports for the respective declarations, I think it is ok to add an
     appropriate library path to your project aswell.

     It seems the DX-SDK does not end up in the LIB environment variable
     for the VS command prompt aswell, though I see it added in the
     Visual Studio settings.


 I only suggest the DXSDK lib in particular for a few reasons:
   1. It's a really standard Microsoft lib, not just some 3rd party thing.
   2. Being a Microsoft lib, it integrates into Visual Studio
 automatically when installed, and it's necessary to do basically any
 multimedia in windows.
   3. It's been integrated into the Windows 8 SDK from VS2012 and on
 (that's why the stand-alone package is quite old), but for the sake of
 'it just works', for prior versions of Visual Studio (which we do
 support), the path needs to be added.

 Ie, there's a risk of VS2012 users saying "well it works for me!", but
 the VS2010 users complaining that it doesn't seem to work for them, and
 then scratching heads why it works for some but not others.


With the option to include C++ libraries, the DX-SDK libraries will be 
found, too. At least from within Visual D...
Oct 17 2013
next sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 17.10.2013 23:20, Rainer Schuetze wrote:

 I think msbuild has good dependency handling


I meant msbuild has _no_ good dependency handling.
Oct 17 2013
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 18 October 2013 07:20, Rainer Schuetze <r.sagitario gmx.de> wrote:


 On 17.10.2013 10:41, Manu wrote:


 Hmmm, I tend to think that sc.ini should be ignored/overridden entirely
 under VisualD.
 Visual Studio has all its own places to configure paths and options.

 Anyone who runs more than one version of Visual Studio has to
 micro-manage sc.ini, which is really annoying.
 As a VisualD user, I expect to be able to access all settings and paths
 in Visual Studio, and they should be relevant for the version of Visual
 Studio in use.

 At least that's my take on it, from an end-user perspective.


 Makes sense, though I'm unsure how to stop dmd from interpreting sc.ini.
 Adding an empty sc.ini into the project folder could work, but is a bit
 ugly.



Perhaps ask Walter to add a command-line option which would ignore sc.ini
and expect all options usually presented in sc.ini to be explicitly given
on the command line?
Something to that effect I suppose. Not sure... :/


On a side note, Visual Studio tends to maintain it's default settings in

 property sheets (you can access the x64 defaults under
 Microsoft.Cpp.x64.user under the Property Manager). I wonder if VisualD
 should also store defaults in the same place, but then I noticed that
 VisualD project's don't seem to have any presence in the Property
 Manager... I guess it's a special project type, and therefore subvert's
 MSBuild? I don't really know how all that stuff fits together.


 When I started work on Visual D, VS2008 was the current version and it did

 build on top of msbuild.

 Even with VS2010, I don't like msbuild. I think msbuild has good
 dependency handling, see the Intel Compiler integration which is horrible.
 My impression is that MS subverts msbuild for C++ to make it acceptable.



Fair enough.
So property sheet stuff is all part of MSBuild is it not? Or maybe that's
wrong?

My point was that as an observation, MS seems to have moved a lot of the
default compiler configuration into those property sheets which you can
configure through the property manager.
I'm not sure if that's all MSBuild-specific, but it seems to be a fairly
nice way to collect that sort of data, in nice little XML files and a
convenient property grid type editor.
If that's the standard go-to location to configure the default compiler
options, I wonder if VisualD should also try and use that? Rather than
having lots of custom UI for VisualD global options.
I can imagine having a suite of property sheets for each
compiler+architecture:
  Where MS provides: Microsoft.Cpp.x64.user (and friends) for instance,
VisualD might maintain a suite something like:
    VisualD.Dmd.x86.user, VisualD.Dmd.x64.user, VisualD.Gdc.x86.user,
VisualD.Gdc.x64.user, VisualD.Ldc.x86.user, VisualD.Ldc.x64.user... ??

The problem I see (and the reason I was thinking on it in the first place),
is that the VisualD options under 'Options->Projects and Solutions->Visual
D Settings->XXX Directories' don't seem to be rich enough to properly
configure defaults for each compiler, and not for each architecture. In
particular, under 'DMD Directories' there is 'Library Paths', but no
separation for x86 and x64, which makes that box quite unusable. I'm also
not sure what 'Executable paths' is for, but considering the 32bit tools
are in dmd2/windows/bin and the 64bit tools are provided by MS, I'm not
sure what to make of it.

This is obviously not stuff that needs urgent attention, but since we're on
the topic of trying to tighten up the experience to make it intuitive and
fool-proof, these are all details worth considering.


You know, thinking on it, it's kinda strange in a sense that D should

 have completely distinct library paths at all. It might be useful in
 VisualD to add all the C/C++ x64 library paths as standard link paths
 aswell.
 Surely it's reasonable as a Visual Studio end-user to assume that any
 libs available to C/C++ should also be available to D too? These are
 'system libs' after all. At least, they've been registered with VS as if
 they are.


 I tend to agree. I'll see if I can find the C++ settings somewhere, so I
 can add a switch to add the library paths automatically.

 I think we'll need different global settings for Win32 and Win64, too.



= VS2010 uses property sheets, which are separated by architecture to give


the defaults.
But yeah, you're right, we already lack a distinction between the global
configuration for x86/x64 in the main options, so it probably needs to be
addressed one way or another.

I think a lot of this will be simplified if your COFF for x86 branch that I
saw in your fork is every polished up ;)
It would be nice to just leave OMF behind and have full access to all
system libraries in Windows for both architectures. The OMF/COFF separation
(and consequent fragmentation of paths and tools) is the source of most of
this complexity.


    I'm not sure we should add too many special cases, everybody has his

     own set of favorite libraries (I haven't touched DirectX for more
     than 10 years). Considering that you probably have to make your own
     imports for the respective declarations, I think it is ok to add an
     appropriate library path to your project aswell.

     It seems the DX-SDK does not end up in the LIB environment variable
     for the VS command prompt aswell, though I see it added in the
     Visual Studio settings.


 I only suggest the DXSDK lib in particular for a few reasons:
   1. It's a really standard Microsoft lib, not just some 3rd party thing.
   2. Being a Microsoft lib, it integrates into Visual Studio
 automatically when installed, and it's necessary to do basically any
 multimedia in windows.
   3. It's been integrated into the Windows 8 SDK from VS2012 and on
 (that's why the stand-alone package is quite old), but for the sake of
 'it just works', for prior versions of Visual Studio (which we do
 support), the path needs to be added.

 Ie, there's a risk of VS2012 users saying "well it works for me!", but
 the VS2010 users complaining that it doesn't seem to work for them, and
 then scratching heads why it works for some but not others.


 With the option to include C++ libraries, the DX-SDK libraries will be
 found, too. At least from within Visual D...


Very true.
Oct 17 2013
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 18.10.2013 05:03, Manu wrote:

     Even with VS2010, I don't like msbuild. I think msbuild has good
     dependency handling, see the Intel Compiler integration which is
     horrible. My impression is that MS subverts msbuild for C++ to make
     it acceptable.


 Fair enough.
 So property sheet stuff is all part of MSBuild is it not? Or maybe
 that's wrong?


It seems it is not tied to msbuild as there are also C++ projects listed 
in VS2008.

But the property manager seems unavailable in the VS shell versions, so 
relying on the property manager would rule out the free IDEs. Supporting 
it in addition might be possible, it mostly seems another way to access 
the project property pages. I'll have to investigate...


 My point was that as an observation, MS seems to have moved a lot of the
 default compiler configuration into those property sheets which you can
 configure through the property manager.
 I'm not sure if that's all MSBuild-specific, but it seems to be a fairly
 nice way to collect that sort of data, in nice little XML files and a
 convenient property grid type editor.
 If that's the standard go-to location to configure the default compiler
 options, I wonder if VisualD should also try and use that? Rather than
 having lots of custom UI for VisualD global options.
 I can imagine having a suite of property sheets for each
 compiler+architecture:
    Where MS provides: Microsoft.Cpp.x64.user (and friends) for instance,
 VisualD might maintain a suite something like:
      VisualD.Dmd.x86.user, VisualD.Dmd.x64.user, VisualD.Gdc.x86.user,
 VisualD.Gdc.x64.user, VisualD.Ldc.x86.user, VisualD.Ldc.x64.user... ??

 The problem I see (and the reason I was thinking on it in the first
 place), is that the VisualD options under 'Options->Projects and
 Solutions->Visual D Settings->XXX Directories' don't seem to be rich
 enough to properly configure defaults for each compiler, and not for
 each architecture. In particular, under 'DMD Directories' there is
 'Library Paths', but no separation for x86 and x64, which makes that box
 quite unusable. I'm also not sure what 'Executable paths' is for, but
 considering the 32bit tools are in dmd2/windows/bin and the 64bit tools
 are provided by MS, I'm not sure what to make of it.

 This is obviously not stuff that needs urgent attention, but since we're
 on the topic of trying to tighten up the experience to make it intuitive
 and fool-proof, these are all details worth considering..


The property manager still configures per project, so it's not a 
replacement for the global options. A better separation for x86/x64 is 
needed, I agree.


         You know, thinking on it, it's kinda strange in a sense that D
         should
         have completely distinct library paths at all. It might be useful in
         VisualD to add all the C/C++ x64 library paths as standard link
         paths
         aswell.
         Surely it's reasonable as a Visual Studio end-user to assume
         that any
         libs available to C/C++ should also be available to D too? These are
         'system libs' after all. At least, they've been registered with
         VS as if
         they are.


     I tend to agree. I'll see if I can find the C++ settings somewhere,
     so I can add a switch to add the library paths automatically.

     I think we'll need different global settings for Win32 and Win64, too.


  >= VS2010 uses property sheets, which are separated by architecture to
 give the defaults.
 But yeah, you're right, we already lack a distinction between the global
 configuration for x86/x64 in the main options, so it probably needs to
 be addressed one way or another.

 I think a lot of this will be simplified if your COFF for x86 branch
 that I saw in your fork is every polished up ;)
 It would be nice to just leave OMF behind and have full access to all
 system libraries in Windows for both architectures. The OMF/COFF
 separation (and consequent fragmentation of paths and tools) is the
 source of most of this complexity.


Let's hope for the release after the currently prepared one...
Oct 18 2013
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 October 2013 04:03, Manu <turkeyman gmail.com> wrote:

 On 18 October 2013 07:20, Rainer Schuetze <r.sagitario gmx.de> wrote:

 On 17.10.2013 10:41, Manu wrote:

 Hmmm, I tend to think that sc.ini should be ignored/overridden entirely
 under VisualD.
 Visual Studio has all its own places to configure paths and options.

 Anyone who runs more than one version of Visual Studio has to
 micro-manage sc.ini, which is really annoying.
 As a VisualD user, I expect to be able to access all settings and paths
 in Visual Studio, and they should be relevant for the version of Visual
 Studio in use.

 At least that's my take on it, from an end-user perspective.


 Makes sense, though I'm unsure how to stop dmd from interpreting sc.ini.
 Adding an empty sc.ini into the project folder could work, but is a bit
 ugly.



 Perhaps ask Walter to add a command-line option which would ignore sc.ini
 and expect all options usually presented in sc.ini to be explicitly given on
 the command line?
 Something to that effect I suppose. Not sure... :/



 On a side note, Visual Studio tends to maintain it's default settings in
 property sheets (you can access the x64 defaults under
 Microsoft.Cpp.x64.user under the Property Manager). I wonder if VisualD
 should also store defaults in the same place, but then I noticed that
 VisualD project's don't seem to have any presence in the Property
 Manager... I guess it's a special project type, and therefore subvert's
 MSBuild? I don't really know how all that stuff fits together.



 When I started work on Visual D, VS2008 was the current version and it did

 build on top of msbuild.

 Even with VS2010, I don't like msbuild. I think msbuild has good
 dependency handling, see the Intel Compiler integration which is horrible.
 My impression is that MS subverts msbuild for C++ to make it acceptable.



 Fair enough.
 So property sheet stuff is all part of MSBuild is it not? Or maybe that's
 wrong?

 My point was that as an observation, MS seems to have moved a lot of the
 default compiler configuration into those property sheets which you can
 configure through the property manager.
 I'm not sure if that's all MSBuild-specific, but it seems to be a fairly
 nice way to collect that sort of data, in nice little XML files and a
 convenient property grid type editor.
 If that's the standard go-to location to configure the default compiler
 options, I wonder if VisualD should also try and use that? Rather than
 having lots of custom UI for VisualD global options.
 I can imagine having a suite of property sheets for each
 compiler+architecture:
   Where MS provides: Microsoft.Cpp.x64.user (and friends) for instance,
 VisualD might maintain a suite something like:
     VisualD.Dmd.x86.user, VisualD.Dmd.x64.user, VisualD.Gdc.x86.user,
 VisualD.Gdc.x64.user, VisualD.Ldc.x86.user, VisualD.Ldc.x64.user... ??


Wishful thinking if you were to believe that one day VisualStudio and
GCC will be ABI compatible  (*cough*)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 18 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-10-18 09:54, Iain Buclaw wrote:


 Wishful thinking if you were to believe that one day VisualStudio and
 GCC will be ABI compatible  (*cough*)


It seems LLVM tries to be compatible with Visual Studio.

-- 
/Jacob Carlborg
Oct 18 2013
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 16 October 2013 at 02:45:26 UTC, Manu wrote:

 I just tried your '-3' version. It has problems.
 [snip]
 2: gcstub64.obj and phobos64.lib are still in 
 D/dmd2/windows/lib. They
 should be moved to lib64/
 3: sc.ini contains: LIB="% P%\..\lib64";"% P%\..\lib"   <- why 
 is '../lib/'
 still present in [Environment64]? That should be removed, it 
 can only lead
 to erroneous attempts to link the OMF libs. Rather have a 
 "can't find lib"
 error, than a weird lib format error that most programmers 
 won't understand.


I agree. It's just a matter of getting Walter on board.  He 
hasn't said yay or nay to lib64 but he's just put sc.ini in the 
repo now for hot steamy pull request action so I think he's 
probably down.


 4: It fails to find the Microsoft libs. Here is the relevant 
 parts of my
 sc.ini as installed by the installer:

 LIB="% P%\..\lib64";"% P%\..\lib"

 ;;;; search path for C Runtime libraries
 ; the following lib path works with VS2008, VS2010, VS2012, 
 VS2013
 ; prepending because 32-bit OMF versions can cause link.exe to 
 fail
 LIB="C:\Program Files (x86)\Microsoft Visual Studio 
 11.0\VC\lib\amd64";%LIB%

 ;;;; search path for Platform libraries
 ; the following lib path works with Windows SDK 6.x and 7.x
 LIB="C:\Program Files (x86)\Windows 
 Kits\8.0\lib\winv6.3\um\x64";%LIB%

 ; the following lib path works with Windows SDK 8.0 and 8.1
 LIB="%WindowsSdkDir%Lib\win8\um\x64";%LIB%


 I have VS2010 and VS2012 installed on a Win8 machine. I have 
 libs in these
 locations:

 C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64  <- 
 this one
 seems to be unknown to the installer. These libs should be used 
 in
 conjunction with VS2010.
 C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64  <- the 
 installer
 refers to %WindowsSdkDir%, which is not present on my system. 
 Use the
 absolute path instead? These libs are to use used in 
 conjunction with
 VS2012.
 C:\Program Files (x86)\Microsoft Visual Studio 
 10.0\VC\lib\amd64  <-
 runtime libs, how to pick which version? Prompt during 
 installation?
 C:\Program Files (x86)\Microsoft Visual Studio 
 11.0\VC\lib\amd64  <-
 runtime libs, how to pick which version? Prompt during 
 installation?

 I should note that I think VisualD needs to do some work here 
 too. VisualD
 should override the linker and lib paths, since it has more 
 information.
 Ie, how does cmdline DMD choose which linker/runtime libs to 
 use? Perhaps a
 prompt during installation? Choose the newest (appears to be 
 the current
 behaviour).
 Whereas VisualD will be running inside of an instance of either 
 VS2010 or
 VS2012 (I use both, this is very common practise) on my 
 machine, and it
 should configure the linker and lib paths appropriately for the 
 version of
 VisualStudio currently in use when building, otherwise there 
 will be link
 troubles against C/C++ libraries also being built in the same 
 solution
 (yes, it's common to have C/C++ and D in the same solution).

 For clarity, on my system, when using the VS2010 compiler, it 
 should use
 these lib paths:
   runtime libs: C:\Program Files (x86)\Microsoft Visual Studio
 10.0\VC\lib\amd64
   windows libs: C:\Program Files (x86)\Microsoft 
 SDKs\Windows\v7.0A\Lib\x64
    <- AFAIK, Microsoft SDKs is the old location, installed with 
 VS2010 and
 earlier.

 When using the VS2012 compiler, it should use these paths:
   runtime libs: C:\Program Files (x86)\Microsoft Visual Studio
 11.0\VC\lib\amd64
   windows libs: C:\Program Files (x86)\Windows 
 Kits\8.0\Lib\win8\um\x64
  <- Windows Kits is the new location, by versions > VS2010 
 (AFAIK).


 The default installation of DMD using your new installer fails 
 to link on
 my machine because %WindowsSdkDir% is not defined on my system, 
 and since
 the 32bit dmd lib path is still present, it tries to link the 
 OMF libs, and
 complains a lot.


Very odd that it replaced one instance of %WindowsSdkDir% but not 
the last one (the installer does a find and replace on some of 
the environment variables with the paths it has detected from the 
registry). It probably has to do with the lack of newline on that 
final line in the file. I'll fix that before this next attempt.



 Elsewhere in the file, you detect VS2010LINKCMD, VS2013LINKCMD, 
 etc. Why
 not also have a matching suite of VS2010LIBPATH="C:\Program 
 Files
 (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64" and friends, 
 and refer to
 them down the bottom as LIB=%VS2010LIBPATH%;%LIB%, along
 with LINKCMD64=%VS2010LINKCMD%.


 section, then
 at the bottom, assign the actual variables used by DMD to the 
 version
 selected by the user when prompted during installation. The 
 result of this
 is that sc.ini will be very easy to read and understand, and if 
 the user
 later wants to switch to another VS version, it'll be obvious 
 to change the



I'm switching to a simpler approach for this next iteration which 
I will post shortly.


 My primary VS environment is VS2010, which is going to be wrong 
 if the
 installer uses a 'prefer newest version' strategy.


I'll see what I can do but I may run out of time to get this in 
for 2.064. I think prefer newest is probably a good default but 
I'm open to hearing why that might not be the case.


 Another question, why use LINKCMD64? Shouldn't it just be 
 LINKCMD, since
 it's under the [Environment64] block? You're not using LIB64, 
 or any others
 like that.


I think others mentioned this but this has already been fixed.
Oct 16 2013
next sibling parent reply "evilrat" <evilrat666 gmail.com> writes:
before i tried x64 i was happy to see its finally coming to the 
masses, but now, *cough* excuse me, how can we develop x64 apps 
if we can't hook debugger? is this something with my 
configuration or something on dmd part which denies any 
possibility to use debuggers at this moment?
Oct 16 2013
parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 17 October 2013 at 06:15:43 UTC, evilrat wrote:

 before i tried x64 i was happy to see its finally coming to the 
 masses, but now, *cough* excuse me, how can we develop x64 apps 
 if we can't hook debugger? is this something with my 
 configuration or something on dmd part which denies any 
 possibility to use debuggers at this moment?


This is above my paygrade. Perhaps Walter or Rainer can answer.
Oct 16 2013
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 17 October 2013 at 05:27:15 UTC, Brad Anderson wrote:

 I'm switching to a simpler approach for this next iteration 
 which I will post shortly.


http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe
Oct 16 2013
parent "evilrat" <evilrat666 gmail.com> writes:
On Thursday, 17 October 2013 at 06:17:57 UTC, Brad Anderson wrote:

 On Thursday, 17 October 2013 at 05:27:15 UTC, Brad Anderson 
 wrote:

 I'm switching to a simpler approach for this next iteration 
 which I will post shortly.


 http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe


now it builds and links just from the box(tested with console dmd 
build). will test with visuld later.
Oct 16 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/16/2013 10:27 PM, Brad Anderson wrote:

 I agree. It's just a matter of getting Walter on board.  He hasn't said yay or
 nay to lib64 but he's just put sc.ini in the repo now for hot steamy pull
 request action so I think he's probably down.


I'll let you guys duke it out and it'll hopefully culminate in a pull request.
Oct 18 2013
prev sibling next sibling parent reply "dnewbie" <run3 myopera.com> writes:
On Wednesday, 16 October 2013 at 01:15:20 UTC, Brad Anderson 
wrote:

 On Tuesday, 15 October 2013 at 06:38:30 UTC, dnewbie wrote:

 VS 2010 Express/Windows SDK 7.0:

 dmd -m64 hello.d
 Can't run 'c:\Program Files (x86)\Microsoft Visual Studio 
 10.0\VC\bin\amd64\link.exe', check PATH

 with dmd-2.064-beta-new-sc.ini-2.exe


 I believe you need the 7.1 SDK.  7.0 does not come with the 
 64-bit toolset.  I'm not certain about the paths in an 
 Express/7.1 setup.

 If you can give me the paths to:

 1. 64-bit link.exe
 2. 64-bit C Runtime libraries (in MSVC this is 
 %VCINSTALLDIR%lib\amd64 but I'm not sure if that comes with 
 Express or with the 7.1 SDK and is located somewhere in SDK's 
 directory structure instead).

 I might be able to this working.


1. 64-bit link.exe:
C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\Bin\amd64\link.exe

2. 64-bit C Runtime libraries:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64

3. 64-bit Windows import libraries:
C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\x64
Oct 16 2013
parent reply Manu <turkeyman gmail.com> writes:
On 17 October 2013 02:51, dnewbie <run3 myopera.com> wrote:


 On Wednesday, 16 October 2013 at 01:15:20 UTC, Brad Anderson wrote:


 On Tuesday, 15 October 2013 at 06:38:30 UTC, dnewbie wrote:


 VS 2010 Express/Windows SDK 7.0:

 dmd -m64 hello.d
 Can't run 'c:\Program Files (x86)\Microsoft Visual Studio
 10.0\VC\bin\amd64\link.exe', check PATH

 with dmd-2.064-beta-new-sc.ini-2.**exe


 I believe you need the 7.1 SDK.  7.0 does not come with the 64-bit
 toolset.  I'm not certain about the paths in an Express/7.1 setup.

 If you can give me the paths to:

 1. 64-bit link.exe
 2. 64-bit C Runtime libraries (in MSVC this is %VCINSTALLDIR%lib\amd64
 but I'm not sure if that comes with Express or with the 7.1 SDK and is
 located somewhere in SDK's directory structure instead).

 I might be able to this working.


 1. 64-bit link.exe:
 C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\amd64\link.exe

 2. 64-bit C Runtime libraries:
 C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64

 3. 64-bit Windows import libraries:
 C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\x64


That looks like VS2008, does VisualD work under VS2008?
Either way, the DMD installer should support detection of those paths too.
Oct 16 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 17.10.2013 01:49, Manu wrote:

 On 17 October 2013 02:51, dnewbie <run3 myopera.com
 <mailto:run3 myopera.com>> wrote:

     1. 64-bit link.exe:
     C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\amd64\link.exe

     2. 64-bit C Runtime libraries:
     C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64

     3. 64-bit Windows import libraries:
     C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\x64


 That looks like VS2008, does VisualD work under VS2008?
 Either way, the DMD installer should support detection of those paths too.


VS2008 is supported, still my preferred version of VS ;-)
Oct 17 2013
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 17 October 2013 at 07:15:48 UTC, Rainer Schuetze 
wrote:

 On 17.10.2013 01:49, Manu wrote:

 On 17 October 2013 02:51, dnewbie <run3 myopera.com
 <mailto:run3 myopera.com>> wrote:

    1. 64-bit link.exe:
    C:\Program Files (x86)\Microsoft Visual Studio 
 9.0\VC\Bin\amd64\link.exe

    2. 64-bit C Runtime libraries:
    C:\Program Files (x86)\Microsoft Visual Studio 
 9.0\VC\lib\amd64

    3. 64-bit Windows import libraries:
    C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\x64


 That looks like VS2008, does VisualD work under VS2008?
 Either way, the DMD installer should support detection of 
 those paths too.


 VS2008 is supported, still my preferred version of VS ;-)


Does VS2008 and SDK 6 work for 64-bit?
Oct 17 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 17.10.2013 21:30, Brad Anderson wrote:

 On Thursday, 17 October 2013 at 07:15:48 UTC, Rainer Schuetze wrote:

 On 17.10.2013 01:49, Manu wrote:

 On 17 October 2013 02:51, dnewbie <run3 myopera.com
 <mailto:run3 myopera.com>> wrote:

    1. 64-bit link.exe:
    C:\Program Files (x86)\Microsoft Visual Studio
 9.0\VC\Bin\amd64\link.exe

    2. 64-bit C Runtime libraries:
    C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64

    3. 64-bit Windows import libraries:
    C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\x64


 That looks like VS2008, does VisualD work under VS2008?
 Either way, the DMD installer should support detection of those paths
 too.


 VS2008 is supported, still my preferred version of VS ;-)


 Does VS2008 and SDK 6 work for 64-bit?


Yes.
Oct 17 2013
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 17 October 2013 at 21:09:02 UTC, Rainer Schuetze 
wrote:

 On 17.10.2013 21:30, Brad Anderson wrote:

 On Thursday, 17 October 2013 at 07:15:48 UTC, Rainer Schuetze 
 wrote:

 On 17.10.2013 01:49, Manu wrote:

 On 17 October 2013 02:51, dnewbie <run3 myopera.com
 <mailto:run3 myopera.com>> wrote:

   1. 64-bit link.exe:
   C:\Program Files (x86)\Microsoft Visual Studio
 9.0\VC\Bin\amd64\link.exe

   2. 64-bit C Runtime libraries:
   C:\Program Files (x86)\Microsoft Visual Studio 
 9.0\VC\lib\amd64

   3. 64-bit Windows import libraries:
   C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\x64


 That looks like VS2008, does VisualD work under VS2008?
 Either way, the DMD installer should support detection of 
 those paths
 too.


 VS2008 is supported, still my preferred version of VS ;-)


 Does VS2008 and SDK 6 work for 64-bit?


 Yes.


Ok, I'll get that added.
Oct 17 2013
parent reply "Temtaime" <temtaime gmail.com> writes:
Hi Brad.
DMD's backend license forbids everyone except backend's authors 
to distribute the compiler.
Oct 17 2013
parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 17 October 2013 at 22:31:39 UTC, Temtaime wrote:

 Hi Brad.
 DMD's backend license forbids everyone except backend's authors 
 to distribute the compiler.


Oh, thanks for the reminder.  I can work around that.
Oct 17 2013
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 16 October 2013 11:15, Brad Anderson <eco gnuk.net> wrote:


 On Tuesday, 15 October 2013 at 06:38:30 UTC, dnewbie wrote:


 VS 2010 Express/Windows SDK 7.0:

 dmd -m64 hello.d
 Can't run 'c:\Program Files (x86)\Microsoft Visual Studio
 10.0\VC\bin\amd64\link.exe', check PATH

 with dmd-2.064-beta-new-sc.ini-2.**exe


 I believe you need the 7.1 SDK.  7.0 does not come with the 64-bit
 toolset.  I'm not certain about the paths in an Express/7.1 setup.


FYI, the 7.1 SDK is a downloadable SDK, it's not included with any version
of Visual Studio.
7.0 and 7.0A (included with VS2008, 2010) certainly do have 64bit libs.

The x64 compiler was available since VS2005 (I don't remember the lib path).
VS2008 uses the 'Microsoft SDKs/Windows/v7.0', and VS2010 uses 'Microsoft
SDKs/Windows/v7.0A'.
The 7.1 package that you can download if obviously in 'Microsoft
SDKs/Windows/v7.1'.

VS2012 was the first to support Windows 8 and the 'metro' API, and for some
reason they messed around with the traditional lib paths.
The new location is the weird 'Windows Kits\8.0'.

If you can give me the paths to:

 1. 64-bit link.exe
 2. 64-bit C Runtime libraries (in MSVC this is %VCINSTALLDIR%lib\amd64 but
 I'm not sure if that comes with Express or with the 7.1 SDK and is located
 somewhere in SDK's directory structure instead).

 I might be able to this working.
Oct 16 2013
parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 17 October 2013 at 00:03:15 UTC, Manu wrote:

 On 16 October 2013 11:15, Brad Anderson <eco gnuk.net> wrote:


 On Tuesday, 15 October 2013 at 06:38:30 UTC, dnewbie wrote:


 VS 2010 Express/Windows SDK 7.0:

 dmd -m64 hello.d
 Can't run 'c:\Program Files (x86)\Microsoft Visual Studio
 10.0\VC\bin\amd64\link.exe', check PATH

 with dmd-2.064-beta-new-sc.ini-2.**exe


 I believe you need the 7.1 SDK.  7.0 does not come with the 
 64-bit
 toolset.  I'm not certain about the paths in an Express/7.1 
 setup.


 FYI, the 7.1 SDK is a downloadable SDK, it's not included with 
 any version
 of Visual Studio.
 7.0 and 7.0A (included with VS2008, 2010) certainly do have 
 64bit libs.

 The x64 compiler was available since VS2005 (I don't remember 
 the lib path).
 VS2008 uses the 'Microsoft SDKs/Windows/v7.0', and VS2010 uses 
 'Microsoft
 SDKs/Windows/v7.0A'.
 The 7.1 package that you can download if obviously in 'Microsoft
 SDKs/Windows/v7.1'.

 VS2012 was the first to support Windows 8 and the 'metro' API, 
 and for some
 reason they messed around with the traditional lib paths.
 The new location is the weird 'Windows Kits\8.0'.


I was referring only to VS 2010 Express which does not include a 
compiler/linker capable of building 64 bit code.  You can get 
them with the 7.1 SDK though.

More information: 
http://stackoverflow.com/questions/1865069/how-to-compile-a-64-bit-application-using-visual-c-2010-express
Oct 16 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 15 October 2013 at 02:17:39 UTC, Brad Anderson wrote:

 There are some pending pull requests[1][2] to get automatic 
 win64 configuration during installation working.  I've prepared 
 a dmd 2.064-beta installer which includes these unmerged 
 changes which you can download here:

 http://gnuk.net/dmd-2.064-beta-new-sc.ini.exe


Third attempt with help/ideas from Rainer:

http://gnuk.net/dmd-2.064-beta-new-sc.ini-3.exe

I've removed ...-2.exe to avoid confusion.
Oct 15 2013
prev sibling next sibling parent reply "evilrat" <evilrat666 gmail.com> writes:
On Tuesday, 15 October 2013 at 02:17:39 UTC, Brad Anderson wrote:

 This installer also includes support for automatically 
 downloading the Visual D installer and running it (another yet 
 to be merged pull request[3]).


with sc-2 config it is almost useless with VisualD, hope next 
version will be more usable :)

also, does anyone knows why it fails to start debugger on x64 
binary using  VisualD?
Oct 16 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 16.10.2013 18:05, evilrat wrote:

 also, does anyone knows why it fails to start debugger on x64 binary
 using  VisualD?


Are you using VS2012 shell? I was experiencing the same problem, that is 
a bug in the shell installer.

The newer Visual D installers fix this problem, the latest is currently 
http://www.dsource.org/projects/visuald/browser/downloads/VisualD-v0.3.37rc4.exe

If you try to use mago as the debugger: it does not (yet) support x64, 
you have to switch to the VS debugger.
Oct 17 2013
parent "evilrat" <evilrat666 gmail.com> writes:
On Thursday, 17 October 2013 at 07:13:20 UTC, Rainer Schuetze 
wrote:

 On 16.10.2013 18:05, evilrat wrote:

 also, does anyone knows why it fails to start debugger on x64 
 binary
 using  VisualD?


 Are you using VS2012 shell? I was experiencing the same 
 problem, that is a bug in the shell installer.

 The newer Visual D installers fix this problem, the latest is 
 currently 
 http://www.dsource.org/projects/visuald/browser/downloads/VisualD-v0.3.37rc4.exe

 If you try to use mago as the debugger: it does not (yet) 
 support x64, you have to switch to the VS debugger.


yes i have vs2012 shell on my machine. thanks it works now 0_0
Oct 17 2013
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
Attempt four: http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe

This one has a couple more changes to the dmd2beta.zip it is 
downloading from my server.

1. dmd.exe has been replaced with one built from 2.064 branch 
HEAD (so I didn't have to use LINKCMD64).
2. lib64 has been added and phobos64.lib and gcstub64.lib have 
been moved into there from lib.
Oct 16 2013
next sibling parent reply Manu <turkeyman gmail.com> writes:
That one's working for me.
It still looks a little funny though:

; default to 32-bit linker (can generate 64-bit code) that has a common path
; for VS2010, VS2012, and VS2013. This will be overridden below if the
; installer detects VS.
LINKCMD=%VCINSTALLDIR%\bin\link.exe

;
-----------------------------------------------------------------------------
; This enclosed section is specially crafted to be activated by the Windows
; installer when it detects the actual paths to VC and SDK installations so
; modify this in the default sc.ini within the git repo with care
;
; End users: You can fill in the path to VC and Windows SDK and uncomment
out
; the appropriate LINKCMD to manually enable support

; Windows installer replaces the following lines with the actual paths
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\
WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.0\


Notice that it refers to LINKCMD=%VCINSTALLDIR%\... at the top, but
VCINSTALLDIR is not set until down lower.
Then later in the file:

; Platform libraries (Windows SDK 8)
LIB=%LIB%;"%WindowsSdkDir%\Lib\win8\um\x64"

; Platform libraries (Windows SDK 7)
LIB=%LIB%;"%WindowsSdkDir%\Lib\x64"

The first one (Win8 SDK) is correct, but the second path (Win7 SDK) doesn't
exist. The Win7 SDK is at "Microsoft SDKs\Windows\v7.0A" on my machine
(installed by VS2010).
None of this seems to cause DMD to fail, but it may be confusing to have
technically erroneous settings.


On 17 October 2013 16:16, Brad Anderson <eco gnuk.net> wrote:


 Attempt four: http://gnuk.net/dmd-2.064-**beta-newsc-lib64-4.exe<http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe>

 This one has a couple more changes to the dmd2beta.zip it is downloading
 from my server.

 1. dmd.exe has been replaced with one built from 2.064 branch HEAD (so I
 didn't have to use LINKCMD64).
 2. lib64 has been added and phobos64.lib and gcstub64.lib have been moved
 into there from lib.
Oct 17 2013
parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 17 October 2013 at 08:08:08 UTC, Manu wrote:

 That one's working for me.
 It still looks a little funny though:


This is all behaving as intended. I'll explain below.


 ; default to 32-bit linker (can generate 64-bit code) that has 
 a common path
 ; for VS2010, VS2012, and VS2013. This will be overridden below 
 if the
 ; installer detects VS.
 LINKCMD=%VCINSTALLDIR%\bin\link.exe

 ;
 -----------------------------------------------------------------------------
 ; This enclosed section is specially crafted to be activated by 
 the Windows
 ; installer when it detects the actual paths to VC and SDK 
 installations so
 ; modify this in the default sc.ini within the git repo with 
 care
 ;
 ; End users: You can fill in the path to VC and Windows SDK and 
 uncomment
 out
 ; the appropriate LINKCMD to manually enable support

 ; Windows installer replaces the following lines with the 
 actual paths
 VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 
 11.0\VC\
 WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.0\


 Notice that it refers to LINKCMD=%VCINSTALLDIR%\... at the top, 
 but
 VCINSTALLDIR is not set until down lower.


There are two goals with the new sc.ini.
1. Work as is with all supported versions of VS so long as the 
user is within the Visual Studio Command Prompt (I take it you 
gamedev guys never had to build early versions of Boost? :P). I 
know you don't use it but many people do.
2. Work outside of the VS Command Prompt if the installer can 
detect a VS installation.

To satisfy both goals I define a LINKCMD that works with all 
versions of Visual Studio (the 32-bit linker which can compile 
64-bit code has the same tail path for every VS version) and add 
to the LIB  the VS/SDK tail paths for all versions of the VS/SDK.

Then in the installer I modify sc.ini to define VCINSTALLDIR and 
WindowsSdkDir based on the detected VS/SDK installation and 
override the LINKCMD with a better version (the 64-bit linker).  
This is why it's not a problem that VCINSTALLDIR is defined below 
it's first use in LINKCMD.  The value is just replaced if 
VCINSTALLDIR gets defined.


 Then later in the file:

 ; Platform libraries (Windows SDK 8)
 LIB=%LIB%;"%WindowsSdkDir%\Lib\win8\um\x64"

 ; Platform libraries (Windows SDK 7)
 LIB=%LIB%;"%WindowsSdkDir%\Lib\x64"

 The first one (Win8 SDK) is correct, but the second path (Win7 
 SDK) doesn't
 exist. The Win7 SDK is at "Microsoft SDKs\Windows\v7.0A" on my 
 machine
 (installed by VS2010).
 None of this seems to cause DMD to fail, but it may be 
 confusing to have
 technically erroneous settings.


Sticking all the possible lib paths in there is a bit unhygienic 
but would extremely unlikely to create a problem in practice so I 
think it's worth it so we can have a much better user experience. 
We can just tell users to use the VS Command Prompt or the 
installer rather than having them modify sc.ini themselves which 
from the the many NG posts about trying and failing to get 64-bit 
working we know is error prone.  This also makes the installer 
less brittle to sc.ini changes than it would be if I did much 
more complicated enabling/disabling.
Oct 17 2013
prev sibling parent reply "kdmult" <kdmult ya.ru> writes:
On Thursday, 17 October 2013 at 06:16:15 UTC, Brad Anderson wrote:

 Attempt four: http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe


While the 64-bit compilation works well the 32-bit one ends with 
the following messages:

---8<---------8<---------8<------

C:\Sandbox\Code>dmd -m64 hello.d


C:\Sandbox\Code>hello.exe

Hello world!

C:\Sandbox\Code>dmd -m32 hello.d
OPTLINK (R) for Win32  Release 8.00.13
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
C:\Sandbox\D\DMD2\WINDOWS\BIN\..\lib\phobos.lib(array)  Offset 
0B04BH Record Type 00C3
  Error 1: Previous Definition Different : 
_D3std5array17__T8AppenderTAyaZ8Appender6__initZ
C:\Sandbox\D\DMD2\WINDOWS\BIN\..\lib\phobos.lib(array)  Offset 
0B05EH Record Type 00C3
  Error 1: Previous Definition Different : 
_D3std5array17__T8AppenderTAyaZ8Appender4Data6__initZ
--- errorlevel 2

---8<---------8<---------8<------
Oct 17 2013
parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 17 October 2013 at 20:30:15 UTC, kdmult wrote:

 On Thursday, 17 October 2013 at 06:16:15 UTC, Brad Anderson 
 wrote:

 Attempt four: http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe


 While the 64-bit compilation works well the 32-bit one ends 
 with the following messages:

 ---8<---------8<---------8<------

 C:\Sandbox\Code>dmd -m64 hello.d


 C:\Sandbox\Code>hello.exe

 Hello world!

 C:\Sandbox\Code>dmd -m32 hello.d
 OPTLINK (R) for Win32  Release 8.00.13
 Copyright (C) Digital Mars 1989-2010  All rights reserved.
 http://www.digitalmars.com/ctg/optlink.html
 C:\Sandbox\D\DMD2\WINDOWS\BIN\..\lib\phobos.lib(array)  Offset 
 0B04BH Record Type 00C3
  Error 1: Previous Definition Different : 
 _D3std5array17__T8AppenderTAyaZ8Appender6__initZ
 C:\Sandbox\D\DMD2\WINDOWS\BIN\..\lib\phobos.lib(array)  Offset 
 0B05EH Record Type 00C3
  Error 1: Previous Definition Different : 
 _D3std5array17__T8AppenderTAyaZ8Appender4Data6__initZ
 --- errorlevel 2

 ---8<---------8<---------8<------


That might be because I didn't update phobos to the latest when I 
replaced dmd.exe. I'll take a look.
Oct 17 2013
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
Fifth and hopefully final version. Not much changed. I put this 
together so it represented the final iteration of my changes that 
will be going into pull requests.

I stopped it from downloading a modified dmd2beta.zip (because of 
the licensing issue I'd forgotten about) and just download the 
original and move phobos64.lib and gcstub64.obj to lib64 in the 
installer.  DMD now supports (as of 2.064 beta 2) LINKCMD in 
Environment64 so I no longer need dmd changes.

http://gnuk.net/dmd-2.064-beta-new-sc.ini-5.exe

People using Visual Studio Express 2010 and Windows SDK 7.0A: 
Sorry, couldn't think of a good solution for that combo.

Thanks to everyone who helped me test.

Relevant pull requests:
https://github.com/D-Programming-Language/dmd/pull/2684
https://github.com/D-Programming-Language/phobos/pull/1652
https://github.com/D-Programming-Language/installer/pull/22 
(putting some finishing touches on this in a moment then calling 
it good)
Oct 19 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 20.10.2013 05:51, Brad Anderson wrote:

 Fifth and hopefully final version. Not much changed. I put this together
 so it represented the final iteration of my changes that will be going
 into pull requests.

 I stopped it from downloading a modified dmd2beta.zip (because of the
 licensing issue I'd forgotten about) and just download the original and
 move phobos64.lib and gcstub64.obj to lib64 in the installer.  DMD now
 supports (as of 2.064 beta 2) LINKCMD in Environment64 so I no longer
 need dmd changes.

 http://gnuk.net/dmd-2.064-beta-new-sc.ini-5.exe

 People using Visual Studio Express 2010 and Windows SDK 7.0A: Sorry,
 couldn't think of a good solution for that combo.

 Thanks to everyone who helped me test.

 Relevant pull requests:
 https://github.com/D-Programming-Language/dmd/pull/2684
 https://github.com/D-Programming-Language/phobos/pull/1652
 https://github.com/D-Programming-Language/installer/pull/22 (putting
 some finishing touches on this in a moment then calling it good)



I finally got around to making a version of Visual D that should work 
for x64 out of the box with both the zip distribution and the new D 
windows installer. Unfortunately it has to override the settings made by 
the installer to sc.ini.

I have prepared a release candidate here:

https://github.com/D-Programming-Language/visuald/releases

3 tiny nitpicks regarding the D installer:
- it does not remember the directory of a previous installation
- it is listed in the "Program and Features" as a mere "D" without any 
further info. That could be a bit more verbose.
- it would be nice if it could also provide a download of the 64-bit 
curl library

The link to the Visual D installer will probably get invalid pretty 
soon, so maybe we should add some "LATEST" file somewhere in the 
repository to grab the link to the latest release?
Oct 28 2013
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Monday, 28 October 2013 at 19:14:17 UTC, Rainer Schuetze wrote:

 On 20.10.2013 05:51, Brad Anderson wrote:

 Fifth and hopefully final version. Not much changed. I put 
 this together
 so it represented the final iteration of my changes that will 
 be going
 into pull requests.

 I stopped it from downloading a modified dmd2beta.zip (because 
 of the
 licensing issue I'd forgotten about) and just download the 
 original and
 move phobos64.lib and gcstub64.obj to lib64 in the installer.  
 DMD now
 supports (as of 2.064 beta 2) LINKCMD in Environment64 so I no 
 longer
 need dmd changes.

 http://gnuk.net/dmd-2.064-beta-new-sc.ini-5.exe

 People using Visual Studio Express 2010 and Windows SDK 7.0A: 
 Sorry,
 couldn't think of a good solution for that combo.

 Thanks to everyone who helped me test.

 Relevant pull requests:
 https://github.com/D-Programming-Language/dmd/pull/2684
 https://github.com/D-Programming-Language/phobos/pull/1652
 https://github.com/D-Programming-Language/installer/pull/22 
 (putting
 some finishing touches on this in a moment then calling it 
 good)



 I finally got around to making a version of Visual D that 
 should work for x64 out of the box with both the zip 
 distribution and the new D windows installer. Unfortunately it 
 has to override the settings made by the installer to sc.ini.


As in, make change to sc.ini itself?  If so, what kind of changes?


 I have prepared a release candidate here:

 https://github.com/D-Programming-Language/visuald/releases


I'll try it out when I get a free moment.


 3 tiny nitpicks regarding the D installer:
 - it does not remember the directory of a previous installation


Good idea. This is easy enough to do.


 - it is listed in the "Program and Features" as a mere "D" 
 without any further info. That could be a bit more verbose.


The creation of the installer predates my interest in D so I 
never know whether things like that were intentional or not.  
"DMD - Digital Mars D Language Compiler" maybe?


 - it would be nice if it could also provide a download of the 
 64-bit curl library


Another thing I'm trying to find some free time to do.  The 
32-bit version could use some updating to a more recent version 
of curl as well. If someone else with more free time wants to do 
this all I did to make it originally was run implib over a curl 
dll to make the OMF import library and put it in a zip file with 
a directory structure that matches dmd's zip so that when the 
installer unzips it everything just falls into place. For 64-bit 
I'd just add the 64-bit curl libraries to the new fangled lib64.


 The link to the Visual D installer will probably get invalid 
 pretty soon, so maybe we should add some "LATEST" file 
 somewhere in the repository to grab the link to the latest 
 release?


Yeah, I wasn't sure how to handle that situation. A web server 
redirect would be the easiest to do normally but D's webserver 
situation is difficult to work with since you have to ask someone 
to make the changes and nobody but Walter, Andrei, and Jan really 
know what the webserver setup is like.

We could also just update the installer periodically. There is no 
reason it needs to be tied to DMD's release cycle.
Oct 29 2013
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 29.10.2013 21:36, Brad Anderson wrote:

 On Monday, 28 October 2013 at 19:14:17 UTC, Rainer Schuetze wrote:

 I finally got around to making a version of Visual D that should work
 for x64 out of the box with both the zip distribution and the new D
 windows installer. Unfortunately it has to override the settings made
 by the installer to sc.ini.


 As in, make change to sc.ini itself?  If so, what kind of changes?


No. Visual D now calls the linker by itself, but extracts settings from 
sc.ini. To allow linking to the C runtime library of the current VS, it 
has to provide the respective path. You can also override the linker 
executable to avoid troubles with the mspdb*.dll dependencies. In 
addition, invoking the 32-bit linker allows monitoring file accesses to 
generate library dependencies.


 I have prepared a release candidate here:

 https://github.com/D-Programming-Language/visuald/releases


 I'll try it out when I get a free moment.


 3 tiny nitpicks regarding the D installer:
 - it does not remember the directory of a previous installation


 Good idea. This is easy enough to do.


 - it is listed in the "Program and Features" as a mere "D" without any
 further info. That could be a bit more verbose.


 The creation of the installer predates my interest in D so I never know
 whether things like that were intentional or not. "DMD - Digital Mars D
 Language Compiler" maybe?


That sounds ok for the "DisplayName". Other entries to fill could be 
"DisplayIcon", "DisplayVersion", "Publisher" and "Comments".


 - it would be nice if it could also provide a download of the 64-bit
 curl library


 Another thing I'm trying to find some free time to do.  The 32-bit
 version could use some updating to a more recent version of curl as
 well. If someone else with more free time wants to do this all I did to
 make it originally was run implib over a curl dll to make the OMF import
 library and put it in a zip file with a directory structure that matches
 dmd's zip so that when the installer unzips it everything just falls
 into place. For 64-bit I'd just add the 64-bit curl libraries to the new
 fangled lib64.


I have a 32-bit version of the curl library built from the same source 
as the 64-bit version (i.e. 7.28.1). This is a single DLL without all 
the additional DLL dependencies.


 The link to the Visual D installer will probably get invalid pretty
 soon, so maybe we should add some "LATEST" file somewhere in the
 repository to grab the link to the latest release?


 Yeah, I wasn't sure how to handle that situation. A web server redirect
 would be the easiest to do normally but D's webserver situation is
 difficult to work with since you have to ask someone to make the changes
 and nobody but Walter, Andrei, and Jan really know what the webserver
 setup is like.


The link on the download page needs updating anyway, so uploading a link 
file should not make it any more problematic.


 We could also just update the installer periodically. There is no reason
 it needs to be tied to DMD's release cycle.


I agree, shouldn't be a big deal, but reducing the number of things to 
update for a release would be nice.
Oct 30 2013