精通GNU Autoconf, Automake和Libtool

需积分: 10 57 浏览量更新于2024-08-02 收藏 1020KB PDF 举报

"GNU Autoconf, Automake 和 Libtool 是三个重要的开源工具，用于软件开发的自动化构建过程。这本书由 Vaughan V. Gary、Ben Elliston、Tom Tromey 和 Ian Lance Taylor 合著，旨在帮助开发者提高生产力和应用的可移植性。书中详细探讨了如何有效地使用这些工具，降低学习曲线，并提供了关于它们之间互动的指导。" GNU Autoconf 是一个自动化配置系统，它允许开发者创建可移植的 configure 脚本，这个脚本能够检测主机系统的特性并生成适应这些特性的 Makefile。Autoconf 使用一系列宏来检查系统特性，然后生成配置脚本，确保软件在各种不同的平台上都能正确编译和链接。 Automake 是一个辅助工具，用于生成符合 GNU 编译标准的 Makefile.in 文件。它处理源代码目录结构，管理库文件和可执行文件的构建，以及确保遵循良好的编程实践，如版本控制和文档生成。Automake 可以与 Autoconf 配合使用，使项目更容易维护和构建。 Libtool 是一个通用库管理工具，它隐藏了不同编译器和链接器之间的差异，简化了动态和静态库的创建。Libtool 提供了一致的接口来编译和链接库，无论是本地还是跨平台，同时处理了库版本管理和依赖关系。本书针对那些对 GNU build 环境不熟悉的开发者，通过详细讲解这三者之间的交互，指导如何最佳地配合使用这些工具。内容可能包括但不限于：如何初始化和配置项目、如何编写和测试 configure 脚本、如何组织源码目录以适应 Automake、如何利用 Libtool 管理库的编译和链接，以及如何处理不同操作系统和编译器的兼容性问题。书中的实例和练习将帮助读者深入理解这些工具的工作原理，提升他们在开源开发环境中的专业技能。此外，作者团队的专业背景确保了内容的权威性和实用性，使得这本书成为开源开发社区的重要参考资料。

These are as follows:

For now, we will do enough to placate Automake:

$ touch NEWS README AUTHORS ChangeLog

$ automake --add-missing

Automake has now produced a 'Makefile.in'. At this point, you may want to take a snapshot of this

directory before we really let loose with automatically generated files.

By now, the contents of the directory are looking fairly complete and reminiscent of the top-level directory of a

GNU package you may have installed in the past:

AUTHORS INSTALL NEWS install-sh mkinstalldirs

COPYING Makefile.am README configure missing

ChangeLog Makefile.in aclocal.m4 configure.in

It should now be possible to package up your tree in a tar file and give it to other users for them to install on their

own systems. One of the make targets that Automake generates in 'Makefile.in' makes it easy to generate

distributions (see Chapter 12, "Rolling Distribution Tarballs" ). A user would merely have to unpack the tar file,

run configure (see Chapter 2, "How to Run Configure, and The Most Useful Standard Makefile Targets" ), and

finally type make all:

$ ./configure

creating cache ./config.cache

checking for a BSD compatible install... /usr/bin/install -c

checking whether build environment is sane... yes

checking whether make sets $@{MAKE@}... yes

checking for working aclocal... found

checking for working autoconf... found

checking for working automake... found

checking for working autoheader... found

checking for working makeinfo... found

checking for gcc... gcc

checking whether the C compiler (gcc ) works... yes

checking whether the C compiler (gcc ) is a cross-compiler... no

checking whether we are using GNU C... yes

checking whether gcc accepts -g... yes

checking how to run the C preprocessor... gcc -E

checking for flex... flex

checking for flex... (cached) flex

checking for yywrap in -lfl... yes

checking lex output file root... lex.yy

checking whether yytext is a pointer... yes

checking for bison... bison -y

updating cache ./config.cache

creating ./config.status

creating Makefile

$ make all

gcc -DPACKAGE=\"foonly\" -DVERSION=\"1.0\" -DYYTEXT_POINTER=1 -I. -I. \

-g -O2 -c main.c

gcc -DPACKAGE=\"foonly\" -DVERSION=\"1.0\" -DYYTEXT_POINTER=1 -I. -I. \

-g -O2 -c foo.c

flex scanner.l && mv lex.yy.c scanner.c

gcc -DPACKAGE=\"foonly\" -DVERSION=\"1.0\" -DYYTEXT_POINTER=1 -I. -I. \

-g -O2 -c scanner.c

bison -y parser.y && mv y.tab.c parser.c

if test -f y.tab.h; then \

if cmp -s y.tab.h parser.h; then rm -f y.tab.h; \

else mv y.tab.h parser.h; fi; \

else :; fi

gcc -DPACKAGE=\"foonly\" -DVERSION=\"1.0\" -DYYTEXT_POINTER=1 -I. -I. \

-g -O2 -c parser.c

gcc -g -O2 -o foonly main.o foo.o scanner.o parser.o -lfl

4.3 Maintaining Input Files

If you edit any of the GNU Autotools input files in your package, you must regenerate the machine-generated files

for these changes to take effect. If you add a new source file to the foonly_SOURCES variable in

'Makefile.am', for instance, you must regenerate the derived file 'Makefile.in'. If you are building

your package, you need to rerun configure to regenerate the site-specific 'Makefile', and then rerun make

to compile the new source file and link it into 'foonly'.

It is possible to regenerate these files by running the required tools, one at a time. As you can see from the

preceding discussion, it can be difficult to compute the dependenciesdoes a particular change require aclocal to

be run? Does a particular change require autoconf to be run? There are two solutions to this problem.

The first solution is to use the autoreconf command. This tool regenerates all derived files by rerunning all the

necessary tools in the correct order. It is somewhat of a brute-force solution, but it works very well, particularly if

you are not trying to accommodate other maintainers, or regular maintenance that would render this command

bothersome.

The alternative is Automake's 'maintainer mode'. By invoking the AM_MAINTAINER_MODE macro from

'configure.in', Automake activates an '--enable-maintainer-mode' option in 'configure'.

Chapter 8, "Bootstrapping," explains this at length.

4.4 Packaging Generated Files

What to do with generated files is keenly contested on the relevant Internet mailing lists. There are two points of

view, and this section presents both of them so that you can try to determine the best policy for your project.

One argument is that generated files should not be included with a package, but rather only the "preferred form" of

the source code should be included. By this definition, 'configure' is a derived file, just like an object file, and

it should not be included in the package. Therefore, the user should use the GNU Autotools to bootstrap themselves

prior to building the package. I believe there is some merit to this purist approach, because it discourages the

practice of packaging derived files.

The other argument is that the advantages of providing these files can far outweigh the violation of good

software-engineering practice already mentioned. By including the generated files, users have the convenience of

not needing to be concerned with keeping up-to-date with all the different versions of the tools in active use. This is

especially true for Autoconf, because 'configure' scripts are often generated by maintainers using locally

modified versions of autoconf and locally installed macros. If the user were to regenerate 'configure', the

result could be different to that intended. Of course, this is poor practice, but it does happen in real life.

I think the answer is to include generated files in the package when the package is going to be distributed to a wide

user community (that is, the general public). For in-house packages, the former argument might make more sense,

because the tools may also be held under version control.

4.5 Documentation and ChangeLogs

As with any software project, it is important to maintain documentation as the project evolves. The documentation

must reflect the current state of the software, but it must also accurately record the changes that have been made in

the past. The GNU coding standard rigorously enforces the maintenance of documentation. Automake, in fact,

implements some of the standard by checking for the presence of a 'ChangeLog' file when automake is run!

A number of files exist, with standardized filenames, for storing documentation in GNU packages. The complete

GNU coding standard, which offers some useful insights, can be found at http://www.gnu.org/prep/standards.html.

Other projects, including in-house projects, can use these same tried-and-true techniques. The purpose of most of

the standard documentation files was outlined earlier (see Section 4.2, "Generated Output Files" ), but the

'ChangeLog' deserves additional treatment.

When recording changes in a 'ChangeLog', one entry is made per person, per day. Logical changes are grouped

together, whereas logically distinct changes (that is, "change sets") are separated by a single blank line. Here is an

example from Automake's own 'ChangeLog':

1999-11-21 Tom Tromey <tromey@cygnus.com>

* automake.in (finish_languages): Only generate suffix rule

when not doing dependency tracking.

* m4/init.m4 (AM_INIT_AUTOMAKE): Use AM_MISSING_INSTALL_SH.

* m4/missing.m4 (AM_MISSING_INSTALL_SH): New macro.

* depend2.am: Use @SOURCE@, @OBJ@, @LTOBJ@, @OBJOBJ@,

and @BASE@. Always use -o.

Another important point to make about 'ChangeLog' entries is that they should be brief. It is not necessary for

an entry to explain in detail why a change was made but rather what the change was. If a change is not

straightforward, the explanation of why belongs in the source code itself. The GNU coding standard offers the

complete set of guidelines for keeping 'ChangeLog's. Although any text editor can be used to create ChangeLog

entries, Emacs provides a major mode to help you write them.

Chapter 5. Writing a Portable 'configure.in'

Writing a portable 'configure.in' is a tricky business. Because you can put arbitrary shell code into

'configure.in', your options seem overwhelming. The first-time Autoconf user asks many questions: What

constructs are portable and what constructs aren't portable? How do I decide what to check for? What shouldn't I

check for? How do I best use Autoconf's features? What shouldn't I put in 'configure.in'? In what order

should I run my checks? When should I look at the name of the system instead of checking for specific features?

Before we talk about the mechanics of deciding what to check for and how to check for it, let's ask ourselves a

simple question: What is portability? Portability is a quality of the code that enables it to be built and run on a

variety of platforms. In the Autoconf context, portability usually refers to the capability to run on Unix-like

systemssometimes including Windows.

When I first started using Autoconf, I had a hard time deciding what to check for in my 'configure.in'. At

the time, I was maintaining a proprietary program that ran only on SunOS 4. However, I was interested in porting it

to Solaris, OSF/1, and possibly Irix.

The approach I took, while workable, was relatively time-consuming and painful: I wrote a minimal

'configure.in' and then proceeded to just try to build my program on Solaris. Each time I encountered a

build problem, I updated 'configure.in' and my source and started again. After it had built correctly, I started

testing to see whether there were runtime problems related to portability.

Because I didn't start with a relatively portable base, and because I was unaware of the tools available to help with

adding Autoconf support to a package (see Chapter 23, "Migrating an Existing Package to GNU Autotools" ), it

was much more difficult than it had to be. If at all possible, it is better to write portable code to begin with.

A large number of Unix-like systems exist in the world, including many systems that, although still running, can

only be considered obsolete. Although it is probably possible to port some programs to all such systems, typically it

is not useful to even try. Porting to everything is a difficult process, especially given that it usually is not possible to

test on all platforms, and that new operating systems, with their own bugs and idiosyncrasies, are released every

year.

We advocate a pragmatic approach to portability: We write our programs to target a fairly large, but also fairly

modern, cross-section of Unix-like systems. As deficiencies are discovered in our portability framework, we update

'configure.in' and our sources, and move on. In practice, this is an effective approach.

If you read a number of 'configure.in's, you will quickly notice that they tend to be written in an unusual

style. You will notice, for instance, that you hardly ever see the '[' program used; instead you will see 'test'

invoked. We won't go into all the details of writing a portable shell script here; instead, we leave that for Chapter

21, "Writing Portable Bourne Shell."

Like other aspects of portability, the approach you take to writing shell scripts in 'configure.in' and

'Makefile.am' should depend on your goals. Some platforms have notoriously broken sh implementations.

For instance, Ultrix sh doesn't implement unset. Of course, the GNU Autotools are written in the most portable

style possible, so as not to limit your possibilities.

Also, it does not really make sense to talk about portable sh programming in the abstract. sh by itself does very

little; most actual work is done by separate programs, each with its own potential portability problems. Some

options are not portable between systems, for instance, and some seemingly common programs do not exist on

every systemso not only do you have to know which sh constructs are not portable, but you also must know

which programs you can (and cannot) use, and which options to those programs are portable.

This seems daunting, but in practice it doesn't seem to be too hard to write portable shell scriptsafter you have

internalized the rules. Unfortunately, this process can take a long time. Meanwhile, a pragmatic "try-and-see"

approach, while noting other portable code you have seen elsewhere, works fairly well. Once again, it pays to be

aware of which architectures you will probably care about; you will make different choices if you are writing an

extremely portable program such as emacs or gcc than if you are writing something that will run only on various

flavors of Linux. Also, the cost of having unportable code in 'configure.in' is relatively low. In general, it is

fairly easy to rewrite pieces on demand as unportable constructs are found.

In addition to the problem of writing portable sh code, another problem confronts first-time 'configure.in'

writers: determining the order in which to run the various tests. Autoconf indirectly (via the autoscan program

covered in Chapter 23) suggests a standard ordering, as described here.

The standard ordering is as follows:

Boilerplate. This section should include standard boilerplate code, such as the call to AC_INIT (which

must be first), AM_INIT_AUTOMAKE, AC_CONFIG_HEADER, and perhaps AC_REVISION.

Options. The next section should include macros that add command-line options to configure, such as

AC_ARG_ENABLE. It is typical to put support code for the option in this section as well, if it is short

enough, like this example from libgcj:

AC_ARG_ENABLE(getenv-properties,

[ disable-getenv-properties

don't set system properties from GCJ_PROPERTIES])

dnl Whether GCJ_PROPERTIES is used depends on the target.

if test -n "$enable_getenv_properties"; then

enable_getenv_properties=${enable_getenv_properties_default-yes}

if test "$enable_getenv_properties" = no; then

AC_DEFINE(DISABLE_GETENV_PROPERTIES)

Programs. Next it is traditional to check for programs that are either needed by the configure process, the

build process, or by one of the programs being built. This usually involves calls to macros such as

AC_CHECK_PROG and AC_PATH_TOOL.

Libraries. Checks for libraries come before checks for other objects visible to C (or C++, or anything else).

This is necessary because some other checks work by trying to link or run a program; by checking for

libraries first, you ensure that the resulting programs can be linked.

Headers. Next come checks for the existence of headers.5.

Typedefs and structures. We do checks for typedefs after checking for headers for the simple reason that6.

typedefs appear in headers, and we need to know which headers we can use before we look inside them.

Functions. Finally we check for functions. These come last because functions have dependencies on the

preceding items: When searching for functions, libraries are needed to correctly link; headers are needed to

find prototypes (this is especially important for C++, which has stricter prototyping rules than C); and

typedefs are needed for those functions that use or return types not built in.

Output. This is done by invoking AC_OUTPUT.8.

This ordering should be considered a rough guideline, and not a list of hard-and-fast rules. Sometimes it is

necessary to interleave tests, either to make 'configure.in' easier to maintain, or because the tests themselves

do need to be in a different order. If your project uses both C and C++, for instance, you might choose to perform

all the C++ checks after all the C checks have been performed, to make 'configure.in' a bit easier to read.

Deciding what to check for is really the central part of writing 'configure.in'. After you have read the

Autoconf reference manual, the "how"s of writing a particular test should be fairly clear. The "when"s might

remain a mysteryand it is just as easy to check for too many things as it is to check for too few.

One notable area of divergence between various Unix-like systems is that the same programs don't exist on all

systems, and, even when they do, they don't always work in the same way. For these problems, we recommend,

when possible, following the advice of the GNU coding standards: Use the most common options from a relatively

limited set of programs. Failing that, try to stick to programs and options specified by POSIX, perhaps augmenting

this approach by doing checks for known problems on platforms you care about.

Checking for tools and their differences is usually a fairly small part of a 'configure' script; more common are

checks for functions, libraries, and the like.

Except for a few core libraries such as 'libc' and, usually, 'libm' and libraries such as 'libX11', which

typically aren't considered system libraries, there is not much agreement about library names or contents between

Unix systems. Still, libraries are easy to handle, because decisions about libraries almost always affect only the

various 'Makefile's. That means that checking for another library typically doesn't require major (or even,

sometimes, any) changes to the source code. Also, because adding a new library test has a small impact on the

development cycleeffectively just rerunning 'configure' and then a relinkyou can effectively adopt a lax

approach to libraries. You can just make things work on the few systems you immediately care about, for instance,

and then handle library changes on an as-needed basis.

Suppose you do end up with a link problem. How do you handle it? The first thing to do is use nm to look through

the system libraries to see whether the missing function exists. If it does, and it is in a library you can use, the

solution is easy: Just add another AC_CHECK_LIB. Note that just finding the function in a library is not enough,

because on some systems, some "standard" libraries are undesirable; 'libucb' is the most common example of a

library that you should avoid.

If you can't find the function in a system library, you have a somewhat more difficult problem: a non-portable

function. There are basically three approaches to a missing function. This chapter discusses functions, but really

these same approaches apply, more or less, to typedefs, structures, and global variables.

The first approach is to write a replacement function and either conditionally compile it, or put it into an

appropriately named file and use AC_REPLACE_FUNCS. For instance, Tcl uses

AC_REPLACE_FUNCS(strstr) to handle systems that have no strstr function.

The second approach is used when there is a similar function with a different name. The idea here is to check for all

the alternatives and then modify your source to use whichever one might exist. The idiom here is to use break in

the second argument to AC_CHECK_FUNCS; this is used both to skip unnecessary tests and to indicate to the

reader that these checks are related. For instance, here is how libgcj checks for inet_aton or inet_addr;

it uses only the first one found:

AC_CHECK_FUNCS(inet_aton inet_addr, break)

Code to use the results of these checks looks something like this:

剩余207页未读，继续阅读

大波波还有个娃

粉丝: 1
资源: 4

精通GNU Autoconf, Automake和Libtool

Autotools -- A Practioner‘s Guide to GNU Autoconf, Automake, and Libtool

GNU+Autoconf+Automake+and+Libtool.pdf

autotools a practitioner's guide to gnu autoconf automake and libtool

autoconf教程推荐

autoconf和automake是什么

如何源码编译libtool

源码编译安装automake请详细列出软件依赖包

arm环境编译udt源码

centos7如何源码编译libtool

x86如何构建xenomai

最新资源