Visual D Build + DMD Bugginess = Bad

dsimcha dsimcha at yahoo.com
Sun Oct 17 11:31:04 PDT 2010


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.sagitario at 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.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?



More information about the Digitalmars-d mailing list