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.
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.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.
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.
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.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 think we'll need different global settings for Win32 and Win64, too.
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...