After describing information about the package, the crucial step comes when you need to build the package. The spec file should contain all the commands needed to build the application or library you want to package. But, and this is the important part, most of the build process should be run from a Makefile or other conventional way to build applications. Using a build tool such as make means that you can test the application outside of the RPM system. You don’t need an RPM to build the application. Instead, you use the RPM to package the application.
The next section cover how to control the build run by rpmbuild by defining commands within your spec files.
9.4.1. Preparing for the build
The %prep section defines the commands to prepare for the build. In most cases, you can run the simple %setup macro. For example:
%prep
%setup -q
This command changes to the build directory, typically /usr/src/redhat/BUILD, and then extracts the source files. This macro expects that at least one of the source files will create the necessary subdirectory under /usr/src/redhat/BUILD. This subdirectory should be named with the package name and version, such as telnet-1.0.1. If you are not using a compressed tar archive that will automatically create the right subdirectory, add the –c option to the %setup macro. The –c option creates the subdirectory for extracting the sources.
The –q command-line option runs in quiet mode with minimal output. The –T option disables the automatic extraction of compressed tar files. You can set the name of the build subdirectory with the –n option.
Normally, the %setup macro deletes the subdirectory prior to extracting the sources. You can disable the directory deletion with the –D option.
Table 10-2 Command-line parameters for %setup
The %setup directive can automatically extract tar, zip, gzip, bzip2, pack, compress, and lzh compressed files. The tar-gzip format is most widely used, though.
Like the %setup macro, the %patch directive applies a patch to the sources. Use this macro in your %prep section if you have patches. You need a %patch directive for each patch.
The %patch directive accepts –p and other command-line parameters for the underlying patch command. The –p option, with a number, such as –p0, tells the patch command to remove that many slashes from the file names within the patch. A –p0 option tells the patch command to remove no slashes, a –p1 option tells patch to remove one slash, and correspondingly, one directory level from the files in the patch. You can also pass other options for the patch command.
Use these options if you need them for the patch command when manually patching the sources. Otherwise, you can set up your %prep section as follows, for a spec file with two patches:
%prep
%setup –q
%patch1
%patch2
Use numbers to identify which patch to apply. For example, %patch0 corresponds to the patch file named with the Patch0: directive.
Note
You must define a separate %patch directive for each patch. In most packages, this format, %patch1, %patch2, and so on, is used.
The %patch directive without a number corresponds to %patch0.
Cross Reference
See the patch and diff online manual pages for more on patches.
In addition to the options supported by the patch command, you can use special options to the %patch directive to control how the directive works. The –P option tells the %patch directive to apply a given patch. For example, to only apply the patch named with the Patch2: directive, use the following %patch directive:
%patch –P 2
Note
This is an uppercase P. The lowercase p performs a different function, described earlier in this section. The -P option is rarely used. Instead, patches are normally applied with %patch0, %patch1, and so on directives.