Help needed testing automatic win64 configuration

[Iain Buclaw]

On 18 October 2013 04:03, Manu <turkeyman at gmail.com> wrote:
> On 18 October 2013 07:20, Rainer Schuetze <r.sagitario at gmx.de> wrote:
>>
>> On 17.10.2013 10:41, Manu wrote:
>>>
>>>
>>> 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.
>
>
> Perhaps ask Walter to add a command-line option which would ignore sc.ini
> and expect all options usually presented in sc.ini to be explicitly given on
> the command line?
> Something to that effect I suppose. Not sure... :/
>
>
>>> 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.
>
>
> Fair enough.
> So property sheet stuff is all part of MSBuild is it not? Or maybe that's
> wrong?
>
> 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... ??
>

Wishful thinking if you were to believe that one day VisualStudio and
GCC will be ABI compatible  (*cough*)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';