GNU Autoconf, Automake, Libtool：Linux项目管理指南

5星 · 超过95%的资源需积分: 10 103 浏览量更新于2024-07-30 2 收藏 1020KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"GNU Autoconf, Automake, and Libtool 是一套在Linux环境下广泛使用的开源项目管理工具，用于自动化软件构建过程，提升开发者的生产力并确保应用程序的可移植性。本书由Vaughan, Gary Ben Elliston, Tom Tromey, Ian Lance Taylor等权威专家合著，旨在教授开发者如何有效地使用这些工具。 GNU Autoconf 是一个配置脚本生成器，它允许开发者自定义编译过程，以适应不同平台的差异。通过Autoconf，开发者可以编写一个configure脚本，该脚本会检测系统环境，确保程序在多种操作系统上都能正确编译和链接。配置脚本通常基于一系列宏，这些宏检查系统特性，如库的存在、特定函数的可用性等，然后生成Makefile.in文件。 GNU Automake 是一个辅助工具，用于生成符合GNU标准的Makefile。Automake处理源码树的组织，确保Makefile.am文件（源代码中的规则）被正确地转换成Makefile.in，最终在configure脚本运行后生成Makefile。Automake简化了管理多个源文件、库和测试的复杂性，同时也支持国际化和本地化。 GNU Libtool 是一个库管理工具，它隐藏了动态和静态库创建的细节，使得开发者可以更专注于代码编写，而不是编译和链接过程。Libtool处理库版本管理，跨平台兼容性，以及如何在不同系统上链接库的问题。它还提供了一致的接口来编译和测试库，无论是在开发阶段还是最终部署。书中详细讨论了这三个工具的交互方式，以及如何让它们协同工作，以优化开发流程。对于没有GNU构建环境经验的开发者来说，这本书将是一份宝贵的指南，帮助他们熟练并自信地掌握这些工具的使用，从而提升开发效率，降低学习曲线。版权信息及作者和审阅者的信息未在提供的内容中给出，但可以推断，这本书由New Riders/MTP出版，是开源开发社区的重要参考资料。"

资源详情

资源推荐

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页未读，继续阅读

onelight1997

粉丝: 52
资源: 13

GNU Autoconf, Automake, Libtool：Linux项目管理指南

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

autotools-idl-开源

SoftwareEngineeringDesignTheoryandPractice.pdf 英文原版

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

在linux上离线源码安装keeplaived

autoconf教程推荐

如何源码编译libtool

autoconf和automake是什么

centos7如何源码编译libtool

centos如何源代码安装automake

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

centos如何源代码下载安装automake

AM_PROG_LIBTOOL: command not found

libmicrohttpd依赖安装

cloog-0.24編譯安裝

configure: error: /bin/bash ./config.sub –enable-debugger failed

centos 安装aarch64-linux-gnu-gcc

centos7.6系统安装arm64位编译环境

x86如何构建xenomai

arm环境编译udt源码

最新资源