Help needed testing automatic win64 configuration

[Rainer Schuetze]

On 17.10.2013 10:41, Manu wrote:
>
>
>
> On 17 October 2013 17:08, Rainer Schuetze <r.sagitario at gmx.de
> <mailto:r.sagitario at 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 
did not use msbuild for C++ (IIRC only for C#). There was no good reason 
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...