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