Linux Programing Hints

 in
Most Linux users have at least heard of Makefiles, but many do not know how powerful a program make is. It is thought of as a tool for maintaining other programs, but it is far more. It can make sense out of chaos in any project where some files are created from other files, whether the end product is a program or a book or an automated post to Usenet. Even if you have never written a makefile, th
Don't get satisfied yet

This makefile works until you define fig82.fig and forget to translate it into fig82.eps. It is also far longer than it needs to be. I will rewrite it to be much smaller, and at the same time work better. I'm going to assume that you are using GNU make, which is the standard make on Linux and some other systems. It is very easy to build on most other systems that you may have.

0: # This is an improved version of the makefile for
1: #  making book.dvi
2: # FIG is a list of all the native xfig drawings
3: FIG = $(wildcard *.fig)
4: # EPS is a list of EPS files to create from the xfig files
5: EPS = $(subst .fig,.eps,$(FIG))
6:
7: %.fig : %.eps
8:          fig2dev -Lps $< $@
9:
10: book.dvi: book.tex $(FIG)
11:         latex book.tex
12:
13: print: book.dvi
14:         dvips -r -Z -q book.dvi

This makefile does everything that the previous one did, and more. It introduces several new concepts along the way, some of which are unique to GNU make. The first, and perhaps the most obvious, is that I did not explicitly list all the .fig or .eps files. Listing all the files requires me to update the makefile each time I add a figure, which is rather error-prone. Using the GNU make wildcard function allows the makefile to automatically update the files correctly, no matter how many figures you add. If you choose to use it, be careful that you really mean to list all the files, and be aware that it will not work under most commercial vendors' versions of make.

GNU make has many functions like wildcard. Like variables, they are enclosed in $(...) (or ${...}), but you can distinguish functions from variables because the functions have embedded spaces. The name of the function comes first, with the argument, or comma-seperated list of arguments, following. They are all documented in Chapter 9, “Functions for Transforming Text”, in the GNU Make manual. wildcard is equivalent to the shell “globbing” that you use every day on the command line (like ls *.fig) and subst works like a very simple version of sed (like sed 's/\.fig/\.eps/g'), replacing each instance of one substring in a string by a different substring.

Another GNU make feature used is called a “pattern rule”. This is like a “suffix rule” as used in all versions of make (suffix rules still work in GNU make, don't worry), but is more powerful. The example given here is equivalent to the suffix rule

.fig.eps:
        fig2dev -Lps $< $@

but the pattern rule is a more general construct. Pattern rules may by preferable if you are writing makefiles for yourself or for projects where you can guarantee that GNU make will be used, and suffix rules are preferable if you are trying to write portable makefiles for all platforms.

The reason pattern rules are more powerful than suffix rules is they can match any sort of pattern, not just suffixes. For example:

foo.% : bar.%

would be a “prefix rule”, which does not exist in other forms of make. Patterns are a more general concept than suffixes, and can be used in other ways in other kinds of rules. The GNU Make manual has examples of this.

The variables $< and $@ are special variables that can be used in rules. The $@ variable stands for the file that is being updated, the target which depends on the files that follow the “:” in the dependency. The $< variable stands for the files upon which the target depends. This is a standard make facility, and does not require GNU make.

Finally, this makefile uses a standard trick of defining a target that doesn't exist. Typing make print will print a copy of your book with everything up-to-date, even though there is no file called print. Similarily, since the first target is the default target, many makefiles have the first rule be a rule called “all:” which does whatever seems right when “everything” is to be built. In fact, the practice of typing “make all” instead of just “make” is so common that even when there is only one program to be built by default, some people will add an all target to their makefile even though it is not at all necessary:

0: all: foo
1:
2: foo: foo.o bar.o baz.o
       <and so on>
instead of
0: foo: foo.o bar.o baz.o
       <and so on>

This is only a taste of make. The GNU Make manual is a gentle, but much more thorough and correct introduction to GNU make, and is distributed with the GNU make source code. It does not assume that you already know how to use any version of make. On a properly installed system, it is available through the info system. The info files can be read from within Emacs (type C-h i from within Emacs) or from a standalone info reader such as info or tkinfo. Alternately, the book can be printed with the TeX typesetting system or ordered from the Free Software Foundation.

Michael K. Johnson is the editor of Linux Journal, but that doesn't keep him from hacking.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState