Unix has a long-established reputation as a good environment to develop under. It's well equipped with tools written by programmers for programmers. These automate away many of the grubby little tasks that would otherwise distract you from concentrating on the most important (and most enjoyable!) aspect of development— your design.

While all the tools you'll need are there and individually well documented, they're not knit together by an integrated development environment (IDE). Finding and assembling them into a kit that suits your needs has traditionally taken considerable effort.

If you're used to a good IDE — the kind of GUI-driven combination of editor, configuration-manager, compiler, and debugger now common on Macintosh and Windows systems — the Unix approach may seem casual, murky, and primitive. But there's actually method in it.

IDEs make a lot of sense for single-language programming in a tool-poor environment. If what you're doing is confined to grinding out C or C++ code by hand and the yard, they're quite appropriate. Under Unix, however, your languages and implementation options are a lot more varied. It's common to use multiple code generators, custom configurators, and many other standard and custom tools.

IDEs do exist under Unix (there are several good open-source ones, including emulations of the major Macintosh and Windows IDEs). But it's difficult to control an open-ended variety of programming tools with them, and they're not much used. Unix encourages a more flexible style, one less exclusively centered on the edit/compile/debug loop.

In this chapter we introduce you to the tactics of development under Unix — building code, managing code configurations, profiling, debugging, and automating away a lot of the drudgery associated with these tasks so you can concentrate on the fun parts. As usual, the exposition focuses more on the architectural picture than the how-to details. When you want how-to details, most of the tools in this chapter are well described in Programming with GNU Software [Loukides-Oram].

Many of these tools automate things that you could do yourself by hand, albeit more slowly and with a higher error rate. The one-time cost of climbing the learning curve should be more than paid off by the ability to write programs more efficiently, and spend less attention on low-level details and more on design.

Unix programmers traditionally learn how to use these tools by osmosis from other programmers, and by exploration over a period of years. If you're a novice, pay careful attention; we're going to try to jump you over a big section of the Unix learning curve by showing you what is possible right at the outset. If you are an experienced Unix programmer in a hurry, you can skip this chapter — but maybe you shouldn't. There might just be some bit of useful lore here that even you don't know.