| My first exposure to make was as an undergraduate at Berkeley in 1979. I was thrilled to be working with the "latest" equipment: a DEC PDP 11/70 with 128 kilobytes of RAM, an ADM 3a "glass tty," Berkeley Unix, and 20 other simultaneous users! Once, when an assignment was due, I remember timing how long it took to log in ”five minutes from typing my username until I got a prompt. After leaving school, it was 1984 before I got to work on Unix again. This time it was as a programmer at NASA's Ames Research Center. We purchased one of the first microcomputer-based Unix systems, a 68000 (not a 68010 or 20) that had a megabyte of RAM and Unix Version 7 ”with only six simultaneous users. My last project there was an interactive satellite data analysis system written in C with a yacc / lex command language, and, of course, make . By 1988, I had gone back to school and was working on a project to build a spline-based geometric modeler. The system consisted of about 120,000 lines of C, spread across 20 or so executables. The system was built using makefile templates that were expanded into normal makefile s by a hand-rolled tool call genmakefile (similar in spirit to imake ). The tool performed simple file inclusion, conditional compilation, and some custom logic to manage source and binary trees. It was a common belief in those days that make required such a wrapper to be a complete build tool. Several years earlier, I had discovered the GNU project and GNU make and realized that the wrapper program was probably unnecessary. I rebuilt the build system without the templates or a generator. To my chagrin, I wound up maintaining the build system for the next four years (a pattern I foolishly repeat to this day). The build system was portable to five flavors of Unix and included separate source and binary trees, automated nightly builds, and support for partial checkouts by developers with the build system filling in the missing objects. My next interesting encounter with make came in 1996, working on a commercial CAD system. It was my job to port 2 million lines of C++ (and 400,000 lines of Lisp) from Unix to Windows NT, using the Microsoft C++ compiler. That's when I discovered the Cygwin project. As an important byproduct of the port, I reworked the build system to support NT. This build system also supported separate source and binary trees, many flavors of Unix, several varieties of graphics support, automated nightly builds and tests, and partial developer checkouts with reference builds. In 2000, I began working in Java writing laboratory information management systems. This was one of the first really different development environments I'd worked in for many years. Most of the programmers came from a Windows background and many seemed to know Java as their first programming language. The build environment consisted almost entirely of the project file generated by a commercial Java Integrated Development Environment (IDE). Although the project file was checked in, it rarely worked "out of the box" and programmers often sat in each other's cubes working through build problems. Of course, I began to write a build system using make , but an odd thing happened . Many of the developers were reluctant to use any command-line tool. Further, many did not have a firm grasp of such concepts as environment variables , command-line options, or an understanding of the tools used to build programs. The IDE hid all of these issues. To address these issues, the build system I was writing became more complex. I began to add better error messages, precondition checking, management of the developer's machine configuration, and support for IDEs. Along the way, I'd read the GNU make manual several dozen times. As I looked for more material, I found the second edition of this book. It was filled with valuable material, but was sadly lacking in details of GNU make . That wasn't surprising, considering its age. The volume had stood the test of time, but by 2003 needed updating. The third edition focuses primarily on GNU make . As Paul Smith (the GNU make maintainer) writes : "Don't hassle with writing portable ` makefile s', use a portable make instead!" |
