Visual D Build + DMD Bugginess = Bad

[Andrej Mitrovic]

Cool stuff, Rainer. Btw, I've noticed there's a new debugger installed
with newer versions of VisualD (mago?). Do I need to set it up to be
used in VS over the default one or is it selected by default after
installation?

On 10/17/10, Rainer Schuetze <r.sagitario at gmx.de> wrote:
> Here's a preliminary new version that includes an option on the general
> project configuration page to switch to single file compilation:
>
> http://www.dsource.org/projects/visuald/browser/downloads/VisualD-v0.3.18rc1.exe
>
> I've used ddmd as a medium sized project for testing. It has more than
> 400 files with most modules mutually importing each other. Some remarks:
>
> - compilation speed is a lot worse, even when compared to what you would
> expect from a similar C/C++ project. It takes almost 8 minutes to
> compile ddmd on my system with single file compilation, while the
> standard compilation takes about 10 seconds.
>
> - the dependency files written by dmd are so bloated that the check that
> selects the files to compile takes almost 20 seconds. This is because
> the size of each dependency file is about 700 kB, summing up to 220 MB
> to scan for imported files. (I had to do some optimizations and file
> operation caching to get the time down from several minutes).
>
> - I consider the single compilation mode only sensible for a large
> collection of modules that have only limited dependencies.
>
> - probably, compilation speed could be way better if semantic analysis
> would only be done on symbols that are actually directly or indirectly
> referred to by the modules passed on the command line. This would need a
> slight modification of the semantic analysis, but would also put the
> promise of independence of lexical order to the test - and would expose
> more of the problems you are currently getting.
>
> This new version also includes some experimental debug/version statement
> highlighting, which has not yet been extensively tested. If it causes
> too many troubles, it can be disabled on the global property page
> Tools->Options->TextEditor->D->Colorizer.
>
> Rainer
>
>
> dsimcha wrote:
>> == Quote from Rainer Schuetze (r.sagitario at gmx.de)'s article
>>> Could it be related to any of these?
>>> http://d.puremagic.com/issues/show_bug.cgi?id=190
>>> http://d.puremagic.com/issues/show_bug.cgi?id=3979
>>
>> Yep, these look like at least part of the problem.  Glad someone else has
>> already
>> reduced them to sane test cases so I don't have to.  Reducing compiler
>> bugs that
>> only seem to occur in non-trivial, multi-module projects to decent test
>> cases is a
>> huge PITA.
>>
>> Anyhow, the project in question is a very messy codebase because it grew
>> very
>> organically.  It's basically a haphazard collection of research prototype
>> algorithms for predicting gene expression from DNA sequence, and every
>> time I
>> think of a new idea, I tend to just put it wherever I can make it fit and
>> almost
>> never bother with non-trivial refactoring.  Therefore, there are cyclic
>> imports
>> **everywhere**.
>>
>>> I have that option on my todo list, but didn't implement it so far
>>> because I was not aware of any problems with compiling multiple files.
>>> I don't know if this is really an option for a larger project, but what
>>> you can do is select "Custom Build Tool" for all files in the "Common
>>> Properties" setting of the project property dialog and enter your own
>>> command line and output file. But be warned: you will not get any
>>> automatic dependency detection.
>>> As editing the settings for a lot of files might be very annoying, you
>>> might want to set it for one file and then edit the project file with a
>>> text editor to copy the settings to other files.
>>> Rainer
>>
>> Since build process automation is by far the biggest reason why I use an
>> IDE
>> instead of a plain old editor, I'd rather just stick with Code::Blocks for
>> now.
>> Could you please bump this up the todo list, given that building multiple
>> files
>> simultaneously is buggy in ways that probably aren't going to get fixed
>> too soon?
>