[oranda]

I left a message on IRC but was told this was the better place to ask.

I've been in the market for a good D IDE, and I think I've settled on Descent as the one showing the most promise. I've been using free tools for a long time now, and I think it would be good to "give back" a little bit.

I think Descent would really profit more than anything from a build system right now. I was told on IRC that one has been started recently. But, I thought I'd offer to help just in case. Many hands make light work.

[asterite]

Awesome!

A little help will be great. Since Robert is working on the build system, he should answer you and tell you how you can work together on that. But I think he went on vacations some days ago, so it'll take some time for him to answer. Some help will definitely be appreciated!

Thanks!

[fraserofthenight]

Hi oranda; thank you very much for the offer. Indeed, I am out of town until Sunday and internet access is a bit expensive here, so I'll keep this brief :P. I would _love_ some builder help. You can check whatr I have by checking the descent.launching folder in descent.internal.launching.debuild , then drop me a line at fraserofthenight@gmail.com with any ideas you have. Thanks very much for your help, and hopefully next week we can get started.

I agree, a builder is one of the most important parts of an IDE. WHat I hope to eventually do is not the activate the builder on launch, but instead integrate the builder somehow so that every time a file is changed it is rebuilt for each build config you have (so if you have a debug build, a profile build and a unittest build, it would be rebuilt fgor each of these when you save the file).

[oranda]

Okay, will do. It might take me a few days to really dig into it, as a quick glance at the structure of the code is just screaming complex at me. Once I figure out how all the little bits fit together though I'll try to come up with some thoughts on how to proceed.

[fraserofthenight]

OK, I'm back.

Yeah, it is kind of complicated . If you're feeling overwhelmed by the Eclipse/Descent side of the build, it would be helpful if you could work on the interface with actual executing application. A simple definition of the interface is in the package descent.launching.compiler, but please add to this interface as necessary. One such implementation of this interface (obviously incomplete) is at descent.internal.launching.dmd.DmdCompilerInterface. If you could figure out how to parse the compiler output (in the DmdResponseInterpreter), etc., and do the same for GDC, that'd be very helpful.

Here's the basic overview of the descent side of the builder (which relies on that interface), all of which is incomplete:

descent.internal.launching.debuild.DebuildBuilder is where the builder is invoked. It very badly needs to be refactored, but if you read down the #build(IProgressMonitor) method, you can basically see how it works (there are some simple comments in there)

descent.internal.launching.debuild.BuildRequest is the major liaison between the build request the user plugin sends (a descent.launching.IExecutableTarget), the user's environment, and the builder. I want to rely on this to get environment info, and the builder to simply perform the steps of the build, but as you can see it needs to be fixed up already.

descent.internal.launching.debuild.ObjectFile refers to an object file that may or may not exist and all the information needed to build it. This means compile options (such as whether it has debug symbols or not, what version identifiers it was built with, etc.), the input file location, and the output file location. Much of the class is dedicated to generating a "mangled" name that hashes as much of this compile info into the object filename as possible.

descent.internal.launching.debuild.RecursiveDependancyCollector is fairly self-explanatory. It does what Gregor's rebuild does, that is, recursively collects the dependencies for a module or set of modules. There's quite a bit of allocation here, so this could be refactored for speed, but once we have the functionality down we can profile to see what's slowing it down.

descent.internal.launching.debuild.ErrorReporter doesn't work right now but will eventually be responsible for attaching markers for the build errors to the associated files.

Thanks again & please send me an e-mail if you have any questions (since that's a lot faster & more often checked than these boards).

All the best,
Robert