Help needed testing automatic win64 configuration

[Brad Anderson]

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%.
> Ie, detect versions of VS present, produce a VS20##LINKCMD and
> VS20##LIBPATH appropriately for each version in their little 
> 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
> reference to the VS20## variables.

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.