Visual D Build + DMD Bugginess = Bad

[Rainer Schuetze]

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?