Help needed testing automatic win64 configuration

[Rainer Schuetze]

On 18.10.2013 05:03, Manu wrote:
>
>     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.
>
>
> Fair enough.
> So property sheet stuff is all part of MSBuild is it not? Or maybe
> that's wrong?

It seems it is not tied to msbuild as there are also C++ projects listed 
in VS2008.

But the property manager seems unavailable in the VS shell versions, so 
relying on the property manager would rule out the free IDEs. Supporting 
it in addition might be possible, it mostly seems another way to access 
the project property pages. I'll have to investigate...

>
> My point was that as an observation, MS seems to have moved a lot of the
> default compiler configuration into those property sheets which you can
> configure through the property manager.
> I'm not sure if that's all MSBuild-specific, but it seems to be a fairly
> nice way to collect that sort of data, in nice little XML files and a
> convenient property grid type editor.
> If that's the standard go-to location to configure the default compiler
> options, I wonder if VisualD should also try and use that? Rather than
> having lots of custom UI for VisualD global options.
> I can imagine having a suite of property sheets for each
> compiler+architecture:
>    Where MS provides: Microsoft.Cpp.x64.user (and friends) for instance,
> VisualD might maintain a suite something like:
>      VisualD.Dmd.x86.user, VisualD.Dmd.x64.user, VisualD.Gdc.x86.user,
> VisualD.Gdc.x64.user, VisualD.Ldc.x86.user, VisualD.Ldc.x64.user... ??
>
> The problem I see (and the reason I was thinking on it in the first
> place), is that the VisualD options under 'Options->Projects and
> Solutions->Visual D Settings->XXX Directories' don't seem to be rich
> enough to properly configure defaults for each compiler, and not for
> each architecture. In particular, under 'DMD Directories' there is
> 'Library Paths', but no separation for x86 and x64, which makes that box
> quite unusable. I'm also not sure what 'Executable paths' is for, but
> considering the 32bit tools are in dmd2/windows/bin and the 64bit tools
> are provided by MS, I'm not sure what to make of it.
>
> This is obviously not stuff that needs urgent attention, but since we're
> on the topic of trying to tighten up the experience to make it intuitive
> and fool-proof, these are all details worth considering..

The property manager still configures per project, so it's not a 
replacement for the global options. A better separation for x86/x64 is 
needed, I agree.

>
>
>         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.
>
>
>  >= VS2010 uses property sheets, which are separated by architecture to
> give the defaults.
> But yeah, you're right, we already lack a distinction between the global
> configuration for x86/x64 in the main options, so it probably needs to
> be addressed one way or another.
>
> I think a lot of this will be simplified if your COFF for x86 branch
> that I saw in your fork is every polished up ;)
> It would be nice to just leave OMF behind and have full access to all
> system libraries in Windows for both architectures. The OMF/COFF
> separation (and consequent fragmentation of paths and tools) is the
> source of most of this complexity.

Let's hope for the release after the currently prepared one...