generating-makefiles.html
来自「linux下gnome编程」· HTML 代码 · 共 1,221 行 · 第 1/3 页
HTML
1,221 行
<HTML><HEAD><TITLE>Generating Makefiles</TITLE><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.61"><LINKREL="HOME"TITLE="Writing GNOME Applications"HREF="index.html"><LINKREL="UP"TITLE="The GNOME Build Environment"HREF="gnome-build.html"><LINKREL="PREVIOUS"TITLE="Creating Your Own Configuration"HREF="creating-configuration.html"><LINKREL="NEXT"TITLE="Dealing with Libraries"HREF="dealing-with-libraries.html"></HEAD><BODYCLASS="SECT1"><DIVCLASS="NAVHEADER"><TABLEWIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">Writing GNOME Applications</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="creating-configuration.html">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom">Chapter 3. The GNOME Build Environment</TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="dealing-with-libraries.html">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="GENERATING-MAKEFILES">Generating Makefiles</A></H1><P> Creating makefiles for your project can be a labor of love or an exercise in futility, and sometimes it is both simultaneously. Much of it is consistent and repetitive between projects. In this section we'll find out what GNU makefiles should look like, and how to greatly simplify their creation. Many tools exist to ease the blow and allow you to get on with writing your code without all the hassle of makefile maintenance. </P><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN414">GNU Makefile Standards</A></H2><P> The GNU project has an official set of guidelines for creating GNU software. These standards help lay out a single established way of doing things, which will help make your software easier to deal with and less susceptible to common coding and portability errors. In this section we will concentrate on the GNU guidelines for creating makefiles, in particular the standard directory locations and makefile targets. If you want to know more about the GNU standards, you can type info standards at the command line of most GNU systems, or visit the standards section of the GNU Web page, at http://www.gnu.org/prep/standards_toc.html. In addition to makefiles, the GNU standards cover program design, code formatting styles, licensing, documentation, and more. </P><P> The GNU standards document defines a long list of makefile variables that point to important directory locations. Most of them refer to install locations. For example, the $(bindir) variable typically points to /usr/local/bin, the directory in which most administrators will want to install program executables for their users. Other types of files end up in different directories- libraries, for example, in $(libdir), which defaults to /usr/local/lib. Installing them into a common directory makes it easier for the system to find them. Rather than having to add a new entry to the search path for every application you install, you have to add only one: /usr/local/bin, for example. </P><P> As we learned earlier, you can change the values of these prefix variables at configure time, by passing different parameters to the configure script. Often, if a software package is less than stable-or perhaps you haven't decided yet if you want to install it permanently on your system-you'll want to install it into a directory path other than /usr/local. Linux distributions typically install their binary packages into the /usr path. Some people like to install GNOME into the /opt/gnome prefix, to keep it separate from other things on their system. This is particularly useful if you want to set up two parallel de- velopment environments, for two versions of GNOME. You might have a stable version in /opt/gnome and a cutting-edge experimental version in /opt/gnome-unstable. If you use a configure script generated by autoconf, all you have to do is specify a new base prefix: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">./configure --prefix=/opt/gnome </PRE></TD></TR></TABLE><P> For a full list of the directories that configure supports, you can run configure --help. The names of these configure options correspond directly to the names of the GNU makefile variables. You can refer to them in your Makefile.in files by using the autoconf substitution syntax because autoconf implicitly calls AC_SUBST on all of them, as part of the AC_INIT macro. For example, you can use configure's value of $(includedir) in your own Makefile.in by referencing @includedir@: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">includedir = @includedir@ </PRE></TD></TR></TABLE><P> As we'll see in the following sections, automake does a lot of this for you automatically, so for the most part you can just start using these variables, trusting autoconf and automake to populate them with the proper values. Table 3.1 lists the most common directory paths, including their default values, how they are constructed, their autoconf substitutions, and a brief description of each. This table uses the ${} notation to highlight the fact that these vari- ables can be used in both makefiles and shell scripts; the $( ) notation is appropriate only in makefiles. </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">Table 3.1 Standard GNU Makefile Path Variables </PRE></TD></TR></TABLE><P> A few items in Table 3.1 bear some additional explanation. First let's look at the distinction between ${prefix} and ${exec_prefix}. Since all other paths are derived from ${prefix}, they will automatically use the same base path, even if it changes. ${prefix} and ${exec_prefix} are usually identical, except that the former points to architecture-independent (i.e., universal) components and the latter points to architecture-dependent (i.e., system-specific) components. You should change them only if you really know what you're doing. If an administrator wanted to export and share the same /usr/local directory across multiple machines with different architectures, she might set ${exec_prefix} to /usr/local/i386 or /usr/local/alpha, for different compilations of the same code base. This would leave the architecture-independent paths untouched while retargeting the architecture-specific files into subdirectories. Thus ${datadir} would point to /usr/local/share in both cases, while ${bindir} would point to /usr/local/i386/bin in the first case and to /usr/local/alpha/bin in the second case. </P><P> Normally you will always use ${includedir}-or an appropriate subdirectory-as an install destination for your C header files. As long as you stick to the defaults, the compiler should implicitly search this path to satisfy #include declarations; you should be able to reference files from this directory in your programs without explicitly listing the path on the compile line, with the -I option. GNU's gcc compiler will implicitly look in both /usr/include and /usr/local/include, so ${includedir}'s default value of /usr/local/include works fine. </P><P> The ${srcdir} variable is the odd one of the bunch. Unlike most of the other install-related variables, ${srcdir} points to someplace inside the currently building source tree. The value of this variable can theoretically differ, depending on which subdirectory of the source tree you're in, but usually it just points to the current directory. If you're using GNU make, you can run builds from outside the source tree; in this case ${srcdir} will be a relative path from the build directory to the source directory. </P><P> The GNU standards document also describes a comprehensive set of makefile targets. By complying with these standard targets, you ensure that people will know how to compile and install your application. Each target has a clear, simple name and well-defined behavior. For example, the standard defines four different types of "clean" targets, each of which deletes a certain category of files within the project. automake supports all of them, plus a few of its own. </P><P> Table 3.2 lists most of the common GNU targets, divided into four general categories according to their general purpose. Most of the targets should be self-explanatory. </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">Table 3.2 Standard GNU Makefile Targets </PRE></TD></TR></TABLE><P> During normal development you will probably use only all, clean, and install, and perhaps uninstall. When you're ready to make a release of your software, you will probably run the distcheck target, which creates a compressed archive (.tar.gz) file of your software package and then tests it to make sure it builds properly. Technically the distcheck target isn't an official part of the GNU standard, but automake always generates it for you, and it is important enough to mention alongside the other targets. It will help protect you and your users from the nightmare of an incomplete release. </P><P> If you want to supply any optional test programs that administrators can run to ensure that the software works before installing it, you should put these under the check target, not under the all target. They should not build by default; administrators should have to explicitly run make check to build the test programs. automake provides some basic support for the check target. </P><P> Normally you'll want to install software with debug information compiled in, unless you are absolutely sure it contains no bugs. If you really don't want debug information, you can install with the install-strip target instead of the normal install target. If the software ends up crashing, however, it will be much harder to diagnose the problem. On most modern operating systems, the extra debug information barely affects performance, if at all, so the main drawback to installing binaries with debug information is the extra hard disk space it uses. </P></DIV><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN433">Using automake</A></H2><P> The autoconf tool does a lot of work to create a configure script for you, but it doesn't do much with your makefiles, other than some simple variable substitution. It provides no common makefile structure, no conventions, nothing to help manage those beasts that can rapidly grow out of control in a complex project. You're still stuck with hand-writing your compile rules. If you want to support the full standard GNU makefile semantics, you will end up repeating a lot of it for each new project you start. </P><P> The automake tool addresses this problem by establishing a makefile template convention that allows you to express your project's build structure in a clear, simple manner. You save this structure in a Makefile.am file, which automake then expands into a Makefile.in file. The configure script can then convert the generated Makefile.in file into a Makefile file. In essence, automake puts an abstraction layer around the build system, freeing you from the drudgery of hand-writing your makefiles. automake also tracks the GNU standard very closely, so you no longer have to update your makefiles when that standard changes; automake will do that for you. You can also change the strictness with which automake adheres to the standards with command line parameters to automake. </P><P> Part of the strength of automake is the closeness with which it integrates itself with its sister tools. The automake distribution includes many extra m4 macros for use with the autoconf system. In addition to supplying numerous new tests to make sure the target system can handle the chores automake needs to do, these macros help cement the integration between automake and autoconf, and between each of these and libtool as well. You'll add these macros to your configure.in file alongside the autoconf macros, sometimes replacing the latter. For example, if you are using autoconf without automake, you should call the AC_CONFIG_HEADER macro; however, if you want to use automake, you should call AM_CONFIG_HEADER instead. Automake's macros begin with the "AM_" prefix to distinguish them from autoconf's macros. </P><P> The only mandatory automake macro is AM_INIT_AUTOMAKE(PACKAGE, VERSION). You use it like this in your configure.in file: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">AM_INIT_AUTOMAKE(myapp, 0.0.1) </PRE></TD></TR></TABLE><P> The first parameter is the PACKAGE name, which is often the name of the main executable. This name will also appear in the distribution file name-for example, myapp-0.0.1.tar.gz. The macro calls AC_DEFINE for both of these parameters, so you can use PACKAGE and VERSION directly in your code. We will make use of this feature later for initializing the GNOME libraries (Section 5.3) and setting up the GNOME documentation system (Chapter 12). </P><P> To make all this macro juggling a little easier on you, automake ships with aclocal, a utility to pull all the external nonautoconf macros into a single file, aclocal.m4 (see Figure 3.2). aclocal grabs whatever automake-specific macros you used in configure.in and adds them to aclocal.m4. It also looks in the local file acinclude.m4; if you've written any custom macros for your software package, you should put them in this file. The aclocal utility will make sure they're shuffled properly into place for autoconf. If your project previously used autoconf but not automake, and if you had some custom macros in an aclocal.m4 file, you should move them all to acinclude.m4. If you don't, aclocal will overwrite them with its autogenerated aclocal.m4 file. </P><DIVCLASS="FIGURE"><ANAME="AEN442"⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?