Help needed testing automatic win64 configuration

[Rainer Schuetze]

On 16.10.2013 13:13, Manu wrote:
> On 16 October 2013 17:16, Rainer Schuetze <r.sagitario at 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.