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.sagita...@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?