I don't know what's the matter with people: they don't learn by understanding, they learn by some other way—by rote or something. Their knowledge is so fragile!
In Chapter 1, I gave an overview of the GNU Autotools and some resources that can help reduce the learning curve required to master them. In this chapter, we're going to step back a little and examine project organization techniques that you can apply to any project, not just one that uses the Autotools.
When you're done reading this chapter, you should be familiar with the common make targets and why they exist. You should also have a solid understanding of why projects are organized the way they are. By the time you finish this chapter, you'll be well on your way to becoming an Autotools expert.
The information provided in this chapter comes primarily from two sources:
If you'd like to brush up on your make syntax, you may also find the GNU Make Manual[13] very useful. If you're particularly interested in portable make syntax (and you probably should be), then check out the POSIX man page for make.[14]
There are two questions you need to ask yourself when you're setting up the build system for an open source software project:
Which platforms will I target?
What do my users expect?
The first is an easy question—you get to decide which platforms to target, but you shouldn't be too restrictive. Open source software projects attain greatness by virtue of the number of people who've adopted them, and arbitrarily limiting the number of platforms reduces the potential size of your community.
The second question is more difficult to answer. First, let's narrow the scope to something manageable. What you really need to ask is: What do my users expect of my build system? Experienced open source software developers become familiar with these expectations by downloading, unpacking, building, and installing thousands of packages. Eventually, they come to know intuitively what users expect of a build system. But, even so, the processes of package configuration, build, and installation vary widely, so it's difficult to define any solid norm.
Rather than taking a survey of every build system out there yourself, you can consult the Free Software Foundation (FSF), sponsor of the GNU project, which has done a lot of the leg work for you. The FSF is one of the best definitive sources for information on free, open source software, including the GCS, which covers a wide variety of topics related to writing, publishing, and distributing free, open source software. Even many non-GNU open source software projects align themselves with the GCS. Why? Well, they invented the concept of free software, and their ideas make sense, for the most part.[15] There are dozens of issues to consider when designing a system that manages packaging, building, and installing software, and the GCS takes most of them into account.
[11] See the Free Software Foundation's GNU Coding Standards at http://www.gnu.org/prep/standards/.
[12] See Daniel Quinlan's overview at http://www.pathname.com/fhs/.
[13] See the Free Software Foundation's GNU Make Manual at http://www.gnu.org/software/make/manual/.
[14] See the Open Group Base Specifications, Issue 6, at http://www.opengroup.org/onlinepubs/009695399/utilities/make.html.
[15] In truth, it's likely that the standards that came about from the BSD project were written much earlier than the standards of the FSF, but the FSF had a big hand in spreading the information to many different platforms and non-system specific software projects. Thus, it had a large part in making these standards publicly visible and widely used.