Awesome. I frankly don't care about compile speeds because the projects in question are fairly small, so even with a horribly inefficient build process build times are negligible. FWIW I use the one at a time builds in CodeBlocks, too, though I parallelize them on my quad core.
I only wanted the one at a time compilation feature as a temporary workaround for compiler bugs that will hopefully be fixed by the time people start using D2 for larger projects. I'll try Visual D again tomorrow and provide some feedback. >From my limited playing around with it, I've already noticed that the debugger works a ton better than any other D debugger I've tried, i.e. possibly good enough that I'll stop using writeln as my main debugging method. == Quote from Rainer Schuetze (r.sagita...@gmx.de)'s article > 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?
