Help needed testing automatic win64 configuration

[Brad Anderson]

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.