On 17.10.2013 10:41, Manu wrote:
>
>
>
> On 17 October 2013 17:08, Rainer Schuetze <r.sagitario@gmx.de
> <mailto:r.sagitario@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...

On 17.10.2013 23:20, Rainer Schuetze wrote:
> I think msbuild has good dependency handling

I meant msbuild has _no_ good dependency handling.

On Thursday, 17 October 2013 at 21:09:02 UTC, Rainer Schuetze wrote:
>
>
> On 17.10.2013 21:30, Brad Anderson wrote:
>> On Thursday, 17 October 2013 at 07:15:48 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 17.10.2013 01:49, Manu wrote:
>>>> On 17 October 2013 02:51, dnewbie <run3@myopera.com
>>>> <mailto:run3@myopera.com>> wrote:
>>>>
>>>>   1. 64-bit link.exe:
>>>>   C:\Program Files (x86)\Microsoft Visual Studio
>>>> 9.0\VC\Bin\amd64\link.exe
>>>>
>>>>   2. 64-bit C Runtime libraries:
>>>>   C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64
>>>>
>>>>   3. 64-bit Windows import libraries:
>>>>   C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\x64
>>>>
>>>>
>>>> That looks like VS2008, does VisualD work under VS2008?
>>>> Either way, the DMD installer should support detection of those paths
>>>> too.
>>>
>>> VS2008 is supported, still my preferred version of VS ;-)
>>
>> Does VS2008 and SDK 6 work for 64-bit?
>
> Yes.

Ok, I'll get that added.

Hi Brad.
DMD's backend license forbids everyone except backend's authors to distribute the compiler.

On Thursday, 17 October 2013 at 22:31:39 UTC, Temtaime wrote:
> Hi Brad.
> DMD's backend license forbids everyone except backend's authors to distribute the compiler.

Oh, thanks for the reminder.  I can work around that.

On 18 October 2013 07:20, Rainer Schuetze <r.sagitario@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... ??

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.


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.


    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...
>

Very true.

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...

On 10/16/2013 10:27 PM, Brad Anderson wrote:
> 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.

I'll let you guys duke it out and it'll hopefully culminate in a pull request.

On 18 October 2013 04:03, Manu <turkeyman@gmail.com> wrote:
> On 18 October 2013 07:20, Rainer Schuetze <r.sagitario@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';

On 2013-10-18 09:54, Iain Buclaw wrote:

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

It seems LLVM tries to be compatible with Visual Studio.

-- 
/Jacob Carlborg