<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 October 2013 17:08, Rainer Schuetze <span dir="ltr"><<a href="mailto:r.sagitario@gmx.de" target="_blank">r.sagitario@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
<br>
On 16.10.2013 13:13, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
It seems the installer failed to replace two occurences of<br>
%WindowsSdkDir%. WindowsSdkDir is set by batch files vsvars32.bat<br>
and friends. I see conflicting goals here:<br>
<br>
1. the installer expands variables WindowsSdkDir and VCINSTALLDIR in<br>
sc.ini to work without running vsvars32.bat. It has to make<br>
decisions on what versions to pick up.<br>
<br>
2. when running dmd by Visual D you want to select settings<br>
according to the current Visual Studio, which means it needs the<br>
unexpanded variables.<br>
<br>
The current option to allow both is to not run the linker through<br>
dmd, but invoke it "manually".<br>
<br>
<br></div><div class="im">
What do you mean by 'manually' exactly?<br>
Is there anything that can be done in VisualD to override these<br>
variables when invoking the compiler?<br>
</div></blockquote>
<br>
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.<br>
</blockquote><div><br></div><div>Hmmm, I tend to think that sc.ini should be ignored/overridden entirely under VisualD.</div><div>Visual Studio has all its own places to configure paths and options.</div><div><br></div><div>
Anyone who runs more than one version of Visual Studio has to micro-manage sc.ini, which is really annoying.</div><div>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.</div>
<div><br></div><div>At least that's my take on it, from an end-user perspective.</div><div><br></div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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.</div>
<div>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.<br>
</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
There's one other detail that I forgot in my prior email; I think it<br>
would be really handy to include the DirectX lib path by default.<br>
It's a very standard MS lib package, and anyone who does multimedia<br>
development will surely have it on their system, and require it to be<br>
hooked up.<br></div>
My DX libs are here: C:\Program Files (x86)\Microsoft DirectX SDK (June<div class="im"><br>
2010)\Lib\x64<br>
It seems I have an environment variable: DXSDK_DIR=C:\Program Files<br>
(x86)\Microsoft DirectX SDK (June 2010)\<br>
It also seems to register a presence in the registry at:<br>
HKEY_LOCAL_MACHINE\SOFTWARE\<u></u>Wow6432Node\Microsoft\DirectX\<u></u>Microsoft<br>
DirectX SDK (June 2010)\InstallPath<br>
<br>
I usually have more faith in the registry, but the env variable is<br>
surely going to be present on everyone's machine.<br>
</div></blockquote>
<br>
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.<br>
<br>
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.<br></blockquote><div><br></div><div>I only suggest the DXSDK lib in particular for a few reasons:</div>
<div> 1. It's a really standard Microsoft lib, not just some 3rd party thing. </div><div> 2. Being a Microsoft lib, it integrates into Visual Studio automatically when installed, and it's necessary to do basically any multimedia in windows.</div>
<div> 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.</div>
<div><br></div><div>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.</div>
</div></div></div>