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.
