I have a Linux partition set up, but for now I do all of my primary development on Windows. When I first stumbled upon D, there were no IDEs around with full support for it. So I adopted a simple method of using a text editor in conjunction with a Windows console. Now it’s been over three years and I still use this approach, even though the landscape has changed and there are now IDEs with good support for D.
The text editor I use is Crimson Editor. It is no longer actively developed, but I’ve been using it for so long now that others seem foreign to me. I like it so much that I even use it with nearly every other language I work with (except Java — Eclipse rocks too much to give up). I just keep a Windows Console open (or MSYS if I’m using C) for execution and output. Crimson Editor can be configured to launch external tools, but I don’t bother. I run dual monitors now, so I usually keep the editor in the primary monitor and the console box in the secondary, along with any documentation I have open. This is all second nature to me now.
There are two compiler implementations available for D right now, the one maintained by Digital Mars (DMD) and a GPLed implementation built on top of GCC (GDC). I use DMD almost exclusively, though I will be needing to work with GDC in the future.
DMD ships with a version of Make. Once upon a time, that was the only option for managing builds of D applications. Now, there are several build tools available that make it easier. Given a single D source module, these tools will parse all imported modules and pass them along to the compiler. The one I use is called Bud (formerly known as ‘Build’). I’ve been using it happily for a couple of years now with another project and see no reason to give it up.
I keep all of my D tools (compilers, build tools, libraries, etc…) in a D directory off of the C drive. To launch the console, I use a batch script that configures the environment, including the relevant paths, and launches cmd.exe. I actually have two such scripts set up, one configured to use the default D standard library (called Phobos) and another to use a community-developed library called Tango.
I also have a D debugger installed (ddbg), but I’ve not yet had a need to use it.
And that’s it. I’m so comfortable in this environment now that it will be hard for me to ever move to another setup. Though if we ever see a D IDE as feature-rich as Eclipse, no one will have to twist my arm.
Technorati Tags: Devlog, D Programming Language, Digital Mars, DMD, GDC, ddbg, Bud
{ 4 } Comments
As for a good IDE, you could try using Code::Blocks. It is a life saviour for me
I’ve written about it on my - not so active - blog.
Ebbe
Yes, I’m aware of Code::Blocks and have it installed. I’ve played with it a bit for both C and D programming, but I don’t see any benefit to using it over my current set up.
As a more portable alternative to make.exe you might want to try mingw32-make (found in the mingw project on sf.net).
Its a port of the GNU Make utility that is available on almost every unix OS (at least on linux ;-)) and it should have much more features.
Although naturally the whole make-stuff is “missing” some D magic (find out which files will be affected when a certain source file changes etc…)
I’ve been a MingW user for years, along with MSYS, and have used it extensively for C and C++ work. I’ve heard, though, that the version of Make that comes with MSYS is an improvement over the MingW version. Though why, I don’t know. MSYS makes a comment about it upon installation.
But I can no longer even imagine using any version of Make for D projects now that I’ve been spoiled by Bud and Rebuild. I never liked using Makefiles, anyway. Now, I consider them archaic and would prefer SCons or other such tools even for C stuff.
Post a Comment