学习CVS和automake、autoconf命令
第一部分 CVS简介
cvs （ Concurrent Version System ）是一个版本控制系统，什么是版本控制系统呢？简单的说，它可以记录程序代码修改的过程，有一个完整的历史记录（ history ）。辟如说，当你在修改程序代码的时候， 不小心写出了一个 bug，但是你可能很久以后才发现多出了这个 bug， 这个时候，cvs 就能很有效的帮助你找出到底是在哪一次的修改中，出现了这个 bug。
也许你会说, 那我每次都把程序保存起来, 用tar 做好备份不就行了，当然, 你可以这样做, 但是这太浪费空间了！ cvs 在版本更改间, 只储存不同的部分, 这样就可以省下很多空间。
在另一个场合里, 更能显示出 cvs 的好处 ，比如多人一起开发软件的时候。 cvs支持远程访问, 用户可以对他要修改的文件加上正在编辑的标志, 让别人知道他要修改这个文件了。 当然, 一个较大的开发队伍，一般还会需要一个 mailing list 用来沟通。毕竟cvs 只是一个管理程序代码的工具, 他并不扮演沟通的角色。 cvs的同类软件还有rcs和sccs。RCS ( Revision Control System ) 可以从FSF获得。SCCS ( Source Code Control System ) 由AT&T在SystemV中引入，现在已经被加入X/Open标准（ Unix 98? ）。比起这些软件，CVS的要优秀得多，特别是在支持多人远程开发方面。由于CVS出现较新，所以使用上反而没有它们普及。当然，如果您熟悉rcs,您会发现学习cvs非常容易。
名词
repository： 意为仓库。在 cvs 里, 它就是你真正存放各历史版本的地方。 pserver： cvs 远程服务器，cvs 有两种工作模式, 一种是 local, 一种是 remote。 一般通过inetd启动pserver。
CVSROOT： 当使用 cvs 的时候, 要设定 CVSROOT这个环境变量, 或是用 -d 选项来指定该参数,该参数指明你的仓库放在哪里。
本地（ local ）cvs
首先, 确定一个 cvsroot，比如：
export CVSROOT="/home/joe/cvsroot/" 建立该目录：
mkdir /home/joe/cvsroot
接着，运行cvs init ：
cvs init
cvs init 会帮你把 cvsroot 初始化。接着, 建立一个要放文件的目录 ( 相当于一个Project )： mkdir /home/joe/cvsroot/cvsdoc
cd /home/joe/work
cvs checkout cvsdoc（ 或者简写为： cvs co cvsdoc ） 你会看到下面的信息： cvs checkout: Updating cvsdoc cvs checkout 会把当前最新的版本拷贝到你的当前目录下。
记住, 不要自己建立 /home/joe/work/cvsdoc, 该目录下还会有一些用于管理的 cvs 相关的信息。
接着, 进入 cvsdoc 目录, 编辑 cvs.doc 这个文件档案，输入一些信息。
然后，运行：
cvs add cvs.txt cvs commit -m "Initial revision." cvs add 就会把 cvs.txt 加入 cvs 维护的文件列表中去。
cvs commit 检查当前目录下所有的在文件列表中的文件，并把对他们的改动加入到仓库中。-m 表示这次 commit 的 message，一般说明此次修改的相关信息。
现在修改一下 cvs.txt，并且，在文件档案的最上面加上 $Id$ 的字样。
改完之后, 再 commit 一次：
cvs commit -m "Adding new stuff."
现在看看我们所做的修改：
cvs log cvs.txt
可以看到：
你会看到每次修改加进去的 message。这对开发者，特别是一个大的项目的开发者，其帮助是不言而喻的。
cvs diff -r 1.1 -r 1.2 cvs.txt
可以看到：
Index: cvs.txt
这样会显示 1.1 和 1.2 版的 diff, 原本有 1.1 版的人, 只需要用这个 patch 就可以了升级到1.2了！
再编辑 cvs.txt, 可以发现最上面的 Id 变长了? 加了一代串文字：
$Id: cvs.txt,v 1.2 2000/09/11 11:55:06 joe Exp $ 这显示这个版本的一些相关信息。
远程（ remote ）cvs
如果我们要做一个比较大的项目，上面讲的本地cvs服务就太简单了，我们要让众多的人可以远程开发程序！ 比如我们要用cvs组织起我们的minigui项目。 检查 /etc/services 有没有这两行，没有请加入：
cvspserver 2401/tcp #CVS network server cvspserver 2401/udp #CVS network server
在 /etc/inetd.conf 加入：
cvspserver stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/home/minigui pserver
mkdir /home/minigui
要是该设置生效，请重启inetd。
添加用户anoncvs, 这是要给匿名cvs 用户使用的帐号，其组为nogroup。 新加一个名为 minigui的 group。 添加参与 minigui开发的用户的帐号, 当然, 把他们的 group 设为 minigui。
cvs -d /home/minigui init
cd /root/minigui, 这是原来已经存在的版本, 现在我们要把它的东西放进 cvs 仓库里： 比如，我们把minigui的库minigui03放到仓库中：
cd minigui03;cvs import –m “the lib” minigui03 joe start
会看到cvs把一个个文件放到仓库中。
cvs import 的语法为：
cvs import -m "log msg" projname vendortag releasetag
vendortag 和releasetag 一般不需要关心，我们这里使用一个用户名和一个start 标志。
我们把其它相关的project也放到cvs仓库中：
cd miniguiapps03 ; cvs import –m “the apps” miniguiapps03 joe start
cd miniguiexec03 ; cvs import –m “the demos” miniguiexec03 joe start
这样，我们就把minigui的一个cvs服务器建立好了。
注意, 一个 user 要远程访问某些project, 他必须拥有适当的权限。比如，minigui03这个目录应该属于组minigui，且组可写。才能使minigui组里的用户可以远程参与minigui库的开发。
现在试试看从远程访问 cvs 服务器。
首先, 在你的机器上建立一个工作目录, 譬如是 /home/joe/work
当你敲入login行时，系统会提示你输入password, 打进去。 www.minigui.org是cvs服务器所在的机器。 该指定被执行后，该 cvsroot
(:pserver:joe@www.minigui.org:/home/minigui) 和加密后的密码会被存在 ~/.cvspass 里。
底下几行取出各个project。最后logout。
cd minigui03
做了一些修改后，可以commit出去：
cvs commit -m "little change"
上面是一般开发者的登陆方法，对于匿名cvs, 可以让其不需要输入口令即可登陆，但是不能让其commint。这需要：
1． 将要开放的project设为全局可读写，因为cvs服务器在操作时要在相应目录下设置读写琐（即需要创建一些临时文件），所以即使是check out 操作，也需要目录可写。
2． 为了让匿名用户只有check out权限，可以在CVSROOT目录下建立一个readers文件，其中每一行是一个用户，这些用户只具有只读权限。比如：
anonymous
anoncvs
guest
jbrowse
3. 利用passwd文件，使匿名用户不能用其它方式登陆。典型为：
在文件CVSROOT/passwd 中：
anoncvs:XR4EZcEs0szik
在文件/etc/passwd 中为：
anoncvs:!:1729:105:Anonymous CVS User:/home/minigui:/bin/false
CVSROOT/passwd文件是cvs提供的一个专用于存放cvs密码的文件。它的典型格式为：
joe:XR4EZcEs0szik:jane
表示cvs用户joe其实是内部用户jane,其cvs密码加密后被存放在第二个字段，这样就将cvs服务与系统的其它部分分离开来，大大地提高了系统的安全性。
上面介绍的是使用需要严格的安全认证的pserver服务器，如果您在局域网内开发程序，则可以使用rsh或者ssh,设置非常简单，服务器端只要开放着rsh或ssh服务器，客户端设置两个环境变量：CVS_RSH与CVSROOT,可以将它们的设置写入预处理脚本，比如使用ssh连接：
$export CVS_RSH="ssh"
$export CVSROOT=":ext:joe@www.minigui.org:/home/minigui"
$ cvs co miniguiexec03
joe@192.9.200.75's password:
输入密码，就可以得到一份miniguiexec03的拷贝了。
小结
以上只是一个简介，cvs还有很多高级功能，如果您需要更详细的信息，请看cvs 的info或者到gnu上下载html版本的manual。
第二部分 使用Automake,Autoconf生成Makefile
在Unix上写过程序的人尤其是用 C 来开发程序的人一般都遇到过 Makefile，用 make 来开发和编译程序的确很方便，可是要写出一个Makefile就不那么简单了。GNU Make 那份几百页的文件，让许多人害怕。当然，现在关于make的文档比较多，不过写一个Makefile总是一件很烦人的事情，GNU Autoconf 及 Automake 这两个软件就是帮助程序开发者轻松产生Makefile 文件的。现在的GNU软件如Apache, MySQL Minigui等都是利用Autoconf,Automake实现自动编译的。用户只要使用 “./configure”, “make”, “make install” 就可以把程序安裝到系统中。
简介
Makefile 基本上就是『目标』(target), 『关联』(dependencies) 和『动作』三者所组成的一系列规则。而 make 就是根据 Makefile 的规则决定如何编译 (compile) 和连接 (link) 程序或者其它动作。当然，make 可做的不只是编译和连接程序，例如 FreeBSD 的 port collection 中，Makefile还可以做到自动下载远程程序，解压缩 (extract) ， 打补丁 (patch)，设定，然后编译，安装到系统中。
Makefile 基本结构虽然很简单，但是妥善运用这些规则就可以变换出许多不同的花样。却也因为这样，许多人刚开始学写Makefile 时会觉得没有规范可以遵循，每个人写出来的Makefile都不大一样，不知道从哪里下手，而且常常会受到开发环境的限制，只要环境参数不同或者路径更改，可能 Makefile 就得跟着修改。虽然有GNU Makefile Conventions (GNU Makefile惯例)制订出一些在进行 GNU 程序设计时写 Makefile 的一些标准和规范，但是其内容很长而且很复杂，并且经常作一些调整，为了减轻程序开发人员维护Makefile 的负担，就出现了Automake。
利用Automake,编程者只需要写一些预先定义好的宏 (macro)，提交给Automake处理，就会产生一个可以供 Autoconf 使用的 Makefile.in文件。再配合使用 Autoconf产生的自动配置文件 configure 即可产生一份符合 GNU Makefile 惯例的 Makeifle 了。
需要的软件
在开始使用 Automake 之前，首先确认你的系统安装有如下软件：
1. GNU Automake
2. GNU Autoconf
3. GNU m4
4. perl
5. GNU Libtool (如果你需要产生 shared library)
最好也使用 GNU C/C++ 编译器 、GNU Make 以及其它 GNU 的工具程序来作为开发的环境，这些工具都是属于 Open Source Software 不但免费而且功能强大。如果你是使用 Red Hat Linux 可以找到所有上述软件的 rpm 文件。
一个简单的例子
Automake 所产生的 Makefile 除了可以做到程序的编译和连接，也可以用来生成文档(如 manual page, info 文件等)，还可以有把源码文件包装起来以供发布，所以程序源代码所存放的目录结构最好符合GNU 的标准惯例，接下来就用一个hello.c 來做为例子。
在工作目录下建立一个新的子目录devel，再在 devel 下建立一个"hello"' 的子目录，这个目录将
作为存放 hello这个程序及其相关文件的地方：
% mkdir devel;cd devel;mkdir hello;cd hello
用编辑器写一个hello.c文件，
接下来就要用 Autoconf 及 Automake 來产生 Makefile 文件了，
1. 用 autoscan 产生一个 configure.in 的原型，执行autoscan 后会产生一个configure.scan 的文件，可以用它作为 configure.in文件的蓝本。
% autoscan
% ls
configure.scan hello.c
2. 编辑 configure.scan文件，如下所示，並且改名为configure.in
3. 执行 aclocal 和 Autoconf ，分別会产生 aclocal.m4 及 configure 两个文件
4. 编辑 Makefile.am 文件，內容如下
5. 执行 ，Automake 会根据Makefile.am 文件产生一些文件，包含最重要的Makefile.in
6. 最后执行 ./configure:
現在你的目录下已经产生了一个 Makefile 文件，输入make指令就可以编译 hello.c 了！
一切工作得很好! 当然，在make install时由于需要向系统目录拷贝文件，您需要有root权限。
更进一步
上述产生Makefile 的过程和以往自行编写的方式非常不一样，使用 Automake 只需用到一些已经定义好的宏就可以了。我们把宏及目标 (target)写在Makefile.am 文件内，Automake 读入 Makefile.am 文件后会把这一串已经定义好的宏展开并产生相对应的
Makefile.in 文件，然后再由configure这个 shell script 根据 Makefile.in 产生合适的Makefile。
具体流程如下所示：
代码 --> [autoscan*] --> [configure.scan] --> configure.in
上图表示在整个过程中要使用的文件及产生出来的文件，有星号 (*) 代表可执行文件。在此示例中可由 Autoconf 及 Automake 工具所产生的额外文件有 configure.scan、aclocal.m4、configure、Makefile.in，需要加入设置的有configure.in 及 Makefile.am。 开发者要书写的文件集中为confiugre.in和Makefile.am,在minigui项目中，我们把一系列的命令集中到一个批处理文件中：autogen.sh:
#!/bin/sh
aclocal
autoheader
Automake --add-missing
Autoconf
只要执行该批处理文件，结合configure.in和Makefile.am，就可以生成需要的Makefile了。
编辑 configure.in 文件
Autoconf 是用来产生 'configure'文件的工具。'configure' 是一个 shell script，它可以自动设定一些编译参数使程序能够条件编译以符合各种不同平台的Unix 系统。Autoconf会读取configure.in 文件然后产生'configure' 这个 shell script。
configure.in 文件内容是一系列GNU m4 的宏，这些宏经Autoconf处理后会变成检查系统特性的shell scripts。 configure.in文件中宏的顺序并没有特别的规定，但是每一个configure.in 文件必须在所有其它宏前加入 AC_INIT 宏，然后在所有其它宏的最后加上 AC_OUTPUT宏。一般可先用 autoscan 扫描原始文件以产生一个 configure.scan 文件，再对 configure.scan 做些修改成 configure.in 文件。在例子中所用到的宏如下：
dnl
这个宏后面的内容不会被处理，可以视为注释
AC_INIT(FILE)
该宏用来检查源代码所在路径，autoscan 会自动产生，一般无须修改它。
AM_INIT_AUTOMAKE(PACKAGE,VERSION)
这个是使用 Automake 所必备的宏，PACKAGE 是所要产生软件的名称，VERSION 是版本编号。
AC_PROG_CC
检查系统可用的C编译器，若源代码是用C写的就需要这个宏。
AC_OUTPUT(FILE)
设置 configure 所要产生的文件，若是Makefile ，configure 便会把它检查出来的结果填充到Makefile.in 文件后产生合适的 Makefile。
实际上，在使用 Automake 时，还需要一些其他的宏，这些额外的宏我们用 aclocal来帮助产生。执行 aclocal会产生aclocal.m4 文件，如果没有特别的用途，不需要修改它，用 aclocal 所产生的宏会告诉 Automake如何动作。
有了 configure.in 及 aclocal.m4两个文件以后，便可以执行 Autoconf来产生 configure 文件了。
编辑Makefile.am 文件
接下来要编辑Makefile.am 文件，Automake 会根据 configure.in 中的宏并在perl的帮助下把Makefile.am 转成 Makefile.in 文件。 Makefile.am 文件定义所要产生的目标：
AUTOMAKE_OPTIONS
设置 Automake 的选项。Automake 主要是帮助开发 GNU 软件的人员来维护软件，所以在执行Automake 时，会检查目录下是否存在标准 GNU 软件中应具备的文件，例如 'NEWS'、'AUTHOR'、
'ChangeLog' 等文件。设置为foreign 时，Automake 会改用一般软件的标准来检查。
bin_PROGRAMS
定义要产生的执行文件名。如果要产生多个执行文件，每个文件名用空白符隔开。
hello_SOURCES
定义 'hello' 这个执行程序所需要的原始文件。如果 'hello'这个程序是由多个原始文件所产生，
必須把它所用到的所有原始文件都列出来，以空白符隔开。假设 'hello' 还需要 'hello.c'、'main.c'、'hello.h' 三个文件的话，则定义
hello_SOURCES= hello.c main.c hello.h
如果定义多个执行文件，则对每个执行程序都要定义相对的filename_SOURCES。
编辑好 Makefile.am 文件，就可以用 Automake --add-missing来产生 Makefile.in。加上 --add-missing 选项来告诉 Automake顺便加入包装一个软件所必须的文件，如果你不使用该选项，Automake可能会抱怨缺少了什么文件。Automake产生出來的 Makefile.in 文件是完全符合 GNU Makefile 惯例的，只要执行 configure这个shell script 便可以产生合适的 Makefile 文件了。
使用 Makefile
利用 configure 所产生的 Makefile文件有几个预先设定的目标可供使用，这里只用几个简述如下：
make all = make
产生设定的目标，既范例中的可执行文件。只敲入make 也可以，此时会开始编译源代码，然后连接并产生执行文件。
make clean
清除之前所编译的可执行文件及目标文件(object file, *.o)。
make distclean
除了清除可执行文件和目标文件以外，也把 configure 所产生的 Makefile 清除掉。 通常在发布软件前执行该命令。
make install
将程序安装到系统中，若源码编译成功，且执行结果正确，便可以把程序安装到系统预先设定的执行文件存放路径中，若用 bin_PROGRAMS 宏的话，程序会被安装到 /usr/local/bin下。
make dist
将程序和相关的文档包装为一个压缩文档以供发布 (distribution) 。执行完在目录下会产生一个以
PACKAGE-VERSION.tar.gz 为名称的文件。PACKAGE 和 VERSION 这两个参数是根据 configure.in 文中AM_INIT_AUTOMAKE(PACKAGE, VERSION) 的定义。在我们的例子中会产生 'hello-1.0.tar.gz' 的文件。
make distcheck
和 make dist 类似，但是加入检查包装以后的压缩文件是否正常，这个目标除了把程序和相关文档包装成 tar.gz 文件外，还会自动把这个压缩文件解开，执行 configure，并执行 make all ，确认编译无错误以后，方显示这个 tar.gz 文件已经准备好并可以发布了。当你看到：
==========================================
hello-1.0.tar.gz is ready for distribution
==========================================
就可以放心地发布您的软件了，检查过关的套件，基本上可以给任何具备 GNU 开发环境的人去重新编译成功。
要注意的是，利用 Autoconf 及 Automake 所产生出來的软件套件是可以在没有安装 Autoconf 及 Automake 的环境使用的，因为 configure 是一个 shell script，它己被设计为可以在一般 Unix 的 sh 这个 shell 下执行。但是如果要修改 configure.in 及 Makefile.am 文件再产生新的 configure 及 Makefile.in 文件时就一定要有 Autoconf 及 Automake 了。
相关资料
通常我们掌握了一些入门知识就可以开始实践了，在有新的需求时，参照相关的文档和别人的例子解决问题，在实践中不断提高。
Autoconf 和 Automake 功能十分强大，可以从它们附带的 info 文档中找到详细的使用说明。或者您喜欢html,可以从gun站点上下载hmtl版本。你也可以从许多现有的GNU 软件或 Open Source 软件如Minigui中找到相关的 configure.in 或 Makefile.am 文件，他们是学习 Autoconf 及 Automake 更多技巧的最佳范例。
cvs （ Concurrent Version System ）是一个版本控制系统，什么是版本控制系统呢？简单的说，它可以记录程序代码修改的过程，有一个完整的历史记录（ history ）。辟如说，当你在修改程序代码的时候， 不小心写出了一个 bug，但是你可能很久以后才发现多出了这个 bug， 这个时候，cvs 就能很有效的帮助你找出到底是在哪一次的修改中，出现了这个 bug。
也许你会说, 那我每次都把程序保存起来, 用tar 做好备份不就行了，当然, 你可以这样做, 但是这太浪费空间了！ cvs 在版本更改间, 只储存不同的部分, 这样就可以省下很多空间。
在另一个场合里, 更能显示出 cvs 的好处 ，比如多人一起开发软件的时候。 cvs支持远程访问, 用户可以对他要修改的文件加上正在编辑的标志, 让别人知道他要修改这个文件了。 当然, 一个较大的开发队伍，一般还会需要一个 mailing list 用来沟通。毕竟cvs 只是一个管理程序代码的工具, 他并不扮演沟通的角色。 cvs的同类软件还有rcs和sccs。RCS ( Revision Control System ) 可以从FSF获得。SCCS ( Source Code Control System ) 由AT&T在SystemV中引入，现在已经被加入X/Open标准（ Unix 98? ）。比起这些软件，CVS的要优秀得多，特别是在支持多人远程开发方面。由于CVS出现较新，所以使用上反而没有它们普及。当然，如果您熟悉rcs,您会发现学习cvs非常容易。
名词
repository： 意为仓库。在 cvs 里, 它就是你真正存放各历史版本的地方。 pserver： cvs 远程服务器，cvs 有两种工作模式, 一种是 local, 一种是 remote。 一般通过inetd启动pserver。
CVSROOT： 当使用 cvs 的时候, 要设定 CVSROOT这个环境变量, 或是用 -d 选项来指定该参数,该参数指明你的仓库放在哪里。
本地（ local ）cvs
首先, 确定一个 cvsroot，比如：
export CVSROOT="/home/joe/cvsroot/" 建立该目录：
mkdir /home/joe/cvsroot
接着，运行cvs init ：
cvs init
cvs init 会帮你把 cvsroot 初始化。接着, 建立一个要放文件的目录 ( 相当于一个Project )： mkdir /home/joe/cvsroot/cvsdoc
cd /home/joe/work
cvs checkout cvsdoc（ 或者简写为： cvs co cvsdoc ） 你会看到下面的信息： cvs checkout: Updating cvsdoc cvs checkout 会把当前最新的版本拷贝到你的当前目录下。
记住, 不要自己建立 /home/joe/work/cvsdoc, 该目录下还会有一些用于管理的 cvs 相关的信息。
接着, 进入 cvsdoc 目录, 编辑 cvs.doc 这个文件档案，输入一些信息。
然后，运行：
cvs add cvs.txt cvs commit -m "Initial revision." cvs add 就会把 cvs.txt 加入 cvs 维护的文件列表中去。
cvs commit 检查当前目录下所有的在文件列表中的文件，并把对他们的改动加入到仓库中。-m 表示这次 commit 的 message，一般说明此次修改的相关信息。
现在修改一下 cvs.txt，并且，在文件档案的最上面加上 $Id$ 的字样。
改完之后, 再 commit 一次：
cvs commit -m "Adding new stuff."
现在看看我们所做的修改：
cvs log cvs.txt
可以看到：
你会看到每次修改加进去的 message。这对开发者，特别是一个大的项目的开发者，其帮助是不言而喻的。
cvs diff -r 1.1 -r 1.2 cvs.txt
可以看到：
Index: cvs.txt
|
再编辑 cvs.txt, 可以发现最上面的 Id 变长了? 加了一代串文字：
$Id: cvs.txt,v 1.2 2000/09/11 11:55:06 joe Exp $ 这显示这个版本的一些相关信息。
远程（ remote ）cvs
如果我们要做一个比较大的项目，上面讲的本地cvs服务就太简单了，我们要让众多的人可以远程开发程序！ 比如我们要用cvs组织起我们的minigui项目。 检查 /etc/services 有没有这两行，没有请加入：
cvspserver 2401/tcp #CVS network server cvspserver 2401/udp #CVS network server
在 /etc/inetd.conf 加入：
cvspserver stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/home/minigui pserver
mkdir /home/minigui
要是该设置生效，请重启inetd。
添加用户anoncvs, 这是要给匿名cvs 用户使用的帐号，其组为nogroup。 新加一个名为 minigui的 group。 添加参与 minigui开发的用户的帐号, 当然, 把他们的 group 设为 minigui。
cvs -d /home/minigui init
cd /root/minigui, 这是原来已经存在的版本, 现在我们要把它的东西放进 cvs 仓库里： 比如，我们把minigui的库minigui03放到仓库中：
cd minigui03;cvs import –m “the lib” minigui03 joe start
会看到cvs把一个个文件放到仓库中。
cvs import 的语法为：
cvs import -m "log msg" projname vendortag releasetag
vendortag 和releasetag 一般不需要关心，我们这里使用一个用户名和一个start 标志。
我们把其它相关的project也放到cvs仓库中：
cd miniguiapps03 ; cvs import –m “the apps” miniguiapps03 joe start
cd miniguiexec03 ; cvs import –m “the demos” miniguiexec03 joe start
这样，我们就把minigui的一个cvs服务器建立好了。
注意, 一个 user 要远程访问某些project, 他必须拥有适当的权限。比如，minigui03这个目录应该属于组minigui，且组可写。才能使minigui组里的用户可以远程参与minigui库的开发。
现在试试看从远程访问 cvs 服务器。
首先, 在你的机器上建立一个工作目录, 譬如是 /home/joe/work
|
当你敲入login行时，系统会提示你输入password, 打进去。 www.minigui.org是cvs服务器所在的机器。 该指定被执行后，该 cvsroot
(:pserver:joe@www.minigui.org:/home/minigui) 和加密后的密码会被存在 ~/.cvspass 里。
底下几行取出各个project。最后logout。
cd minigui03
做了一些修改后，可以commit出去：
cvs commit -m "little change"
上面是一般开发者的登陆方法，对于匿名cvs, 可以让其不需要输入口令即可登陆，但是不能让其commint。这需要：
1． 将要开放的project设为全局可读写，因为cvs服务器在操作时要在相应目录下设置读写琐（即需要创建一些临时文件），所以即使是check out 操作，也需要目录可写。
2． 为了让匿名用户只有check out权限，可以在CVSROOT目录下建立一个readers文件，其中每一行是一个用户，这些用户只具有只读权限。比如：
anonymous
anoncvs
guest
jbrowse
3. 利用passwd文件，使匿名用户不能用其它方式登陆。典型为：
在文件CVSROOT/passwd 中：
anoncvs:XR4EZcEs0szik
在文件/etc/passwd 中为：
anoncvs:!:1729:105:Anonymous CVS User:/home/minigui:/bin/false
CVSROOT/passwd文件是cvs提供的一个专用于存放cvs密码的文件。它的典型格式为：
joe:XR4EZcEs0szik:jane
表示cvs用户joe其实是内部用户jane,其cvs密码加密后被存放在第二个字段，这样就将cvs服务与系统的其它部分分离开来，大大地提高了系统的安全性。
上面介绍的是使用需要严格的安全认证的pserver服务器，如果您在局域网内开发程序，则可以使用rsh或者ssh,设置非常简单，服务器端只要开放着rsh或ssh服务器，客户端设置两个环境变量：CVS_RSH与CVSROOT,可以将它们的设置写入预处理脚本，比如使用ssh连接：
$export CVS_RSH="ssh"
$export CVSROOT=":ext:joe@www.minigui.org:/home/minigui"
$ cvs co miniguiexec03
joe@192.9.200.75's password:
输入密码，就可以得到一份miniguiexec03的拷贝了。
小结
以上只是一个简介，cvs还有很多高级功能，如果您需要更详细的信息，请看cvs 的info或者到gnu上下载html版本的manual。
第二部分 使用Automake,Autoconf生成Makefile
在Unix上写过程序的人尤其是用 C 来开发程序的人一般都遇到过 Makefile，用 make 来开发和编译程序的确很方便，可是要写出一个Makefile就不那么简单了。GNU Make 那份几百页的文件，让许多人害怕。当然，现在关于make的文档比较多，不过写一个Makefile总是一件很烦人的事情，GNU Autoconf 及 Automake 这两个软件就是帮助程序开发者轻松产生Makefile 文件的。现在的GNU软件如Apache, MySQL Minigui等都是利用Autoconf,Automake实现自动编译的。用户只要使用 “./configure”, “make”, “make install” 就可以把程序安裝到系统中。
简介
Makefile 基本上就是『目标』(target), 『关联』(dependencies) 和『动作』三者所组成的一系列规则。而 make 就是根据 Makefile 的规则决定如何编译 (compile) 和连接 (link) 程序或者其它动作。当然，make 可做的不只是编译和连接程序，例如 FreeBSD 的 port collection 中，Makefile还可以做到自动下载远程程序，解压缩 (extract) ， 打补丁 (patch)，设定，然后编译，安装到系统中。
Makefile 基本结构虽然很简单，但是妥善运用这些规则就可以变换出许多不同的花样。却也因为这样，许多人刚开始学写Makefile 时会觉得没有规范可以遵循，每个人写出来的Makefile都不大一样，不知道从哪里下手，而且常常会受到开发环境的限制，只要环境参数不同或者路径更改，可能 Makefile 就得跟着修改。虽然有GNU Makefile Conventions (GNU Makefile惯例)制订出一些在进行 GNU 程序设计时写 Makefile 的一些标准和规范，但是其内容很长而且很复杂，并且经常作一些调整，为了减轻程序开发人员维护Makefile 的负担，就出现了Automake。
利用Automake,编程者只需要写一些预先定义好的宏 (macro)，提交给Automake处理，就会产生一个可以供 Autoconf 使用的 Makefile.in文件。再配合使用 Autoconf产生的自动配置文件 configure 即可产生一份符合 GNU Makefile 惯例的 Makeifle 了。
需要的软件
在开始使用 Automake 之前，首先确认你的系统安装有如下软件：
1. GNU Automake
2. GNU Autoconf
3. GNU m4
4. perl
5. GNU Libtool (如果你需要产生 shared library)
最好也使用 GNU C/C++ 编译器 、GNU Make 以及其它 GNU 的工具程序来作为开发的环境，这些工具都是属于 Open Source Software 不但免费而且功能强大。如果你是使用 Red Hat Linux 可以找到所有上述软件的 rpm 文件。
一个简单的例子
Automake 所产生的 Makefile 除了可以做到程序的编译和连接，也可以用来生成文档(如 manual page, info 文件等)，还可以有把源码文件包装起来以供发布，所以程序源代码所存放的目录结构最好符合GNU 的标准惯例，接下来就用一个hello.c 來做为例子。
在工作目录下建立一个新的子目录devel，再在 devel 下建立一个"hello"' 的子目录，这个目录将
作为存放 hello这个程序及其相关文件的地方：
% mkdir devel;cd devel;mkdir hello;cd hello
用编辑器写一个hello.c文件，
|
接下来就要用 Autoconf 及 Automake 來产生 Makefile 文件了，
1. 用 autoscan 产生一个 configure.in 的原型，执行autoscan 后会产生一个configure.scan 的文件，可以用它作为 configure.in文件的蓝本。
% autoscan
% ls
configure.scan hello.c
2. 编辑 configure.scan文件，如下所示，並且改名为configure.in
|
|
|
|
|
|
更进一步
上述产生Makefile 的过程和以往自行编写的方式非常不一样，使用 Automake 只需用到一些已经定义好的宏就可以了。我们把宏及目标 (target)写在Makefile.am 文件内，Automake 读入 Makefile.am 文件后会把这一串已经定义好的宏展开并产生相对应的
Makefile.in 文件，然后再由configure这个 shell script 根据 Makefile.in 产生合适的Makefile。
具体流程如下所示：
代码 --> [autoscan*] --> [configure.scan] --> configure.in
|
#!/bin/sh
aclocal
autoheader
Automake --add-missing
Autoconf
只要执行该批处理文件，结合configure.in和Makefile.am，就可以生成需要的Makefile了。
编辑 configure.in 文件
Autoconf 是用来产生 'configure'文件的工具。'configure' 是一个 shell script，它可以自动设定一些编译参数使程序能够条件编译以符合各种不同平台的Unix 系统。Autoconf会读取configure.in 文件然后产生'configure' 这个 shell script。
configure.in 文件内容是一系列GNU m4 的宏，这些宏经Autoconf处理后会变成检查系统特性的shell scripts。 configure.in文件中宏的顺序并没有特别的规定，但是每一个configure.in 文件必须在所有其它宏前加入 AC_INIT 宏，然后在所有其它宏的最后加上 AC_OUTPUT宏。一般可先用 autoscan 扫描原始文件以产生一个 configure.scan 文件，再对 configure.scan 做些修改成 configure.in 文件。在例子中所用到的宏如下：
dnl
这个宏后面的内容不会被处理，可以视为注释
AC_INIT(FILE)
该宏用来检查源代码所在路径，autoscan 会自动产生，一般无须修改它。
AM_INIT_AUTOMAKE(PACKAGE,VERSION)
这个是使用 Automake 所必备的宏，PACKAGE 是所要产生软件的名称，VERSION 是版本编号。
AC_PROG_CC
检查系统可用的C编译器，若源代码是用C写的就需要这个宏。
AC_OUTPUT(FILE)
设置 configure 所要产生的文件，若是Makefile ，configure 便会把它检查出来的结果填充到Makefile.in 文件后产生合适的 Makefile。
实际上，在使用 Automake 时，还需要一些其他的宏，这些额外的宏我们用 aclocal来帮助产生。执行 aclocal会产生aclocal.m4 文件，如果没有特别的用途，不需要修改它，用 aclocal 所产生的宏会告诉 Automake如何动作。
有了 configure.in 及 aclocal.m4两个文件以后，便可以执行 Autoconf来产生 configure 文件了。
编辑Makefile.am 文件
接下来要编辑Makefile.am 文件，Automake 会根据 configure.in 中的宏并在perl的帮助下把Makefile.am 转成 Makefile.in 文件。 Makefile.am 文件定义所要产生的目标：
AUTOMAKE_OPTIONS
设置 Automake 的选项。Automake 主要是帮助开发 GNU 软件的人员来维护软件，所以在执行Automake 时，会检查目录下是否存在标准 GNU 软件中应具备的文件，例如 'NEWS'、'AUTHOR'、
'ChangeLog' 等文件。设置为foreign 时，Automake 会改用一般软件的标准来检查。
bin_PROGRAMS
定义要产生的执行文件名。如果要产生多个执行文件，每个文件名用空白符隔开。
hello_SOURCES
定义 'hello' 这个执行程序所需要的原始文件。如果 'hello'这个程序是由多个原始文件所产生，
必須把它所用到的所有原始文件都列出来，以空白符隔开。假设 'hello' 还需要 'hello.c'、'main.c'、'hello.h' 三个文件的话，则定义
hello_SOURCES= hello.c main.c hello.h
如果定义多个执行文件，则对每个执行程序都要定义相对的filename_SOURCES。
编辑好 Makefile.am 文件，就可以用 Automake --add-missing来产生 Makefile.in。加上 --add-missing 选项来告诉 Automake顺便加入包装一个软件所必须的文件，如果你不使用该选项，Automake可能会抱怨缺少了什么文件。Automake产生出來的 Makefile.in 文件是完全符合 GNU Makefile 惯例的，只要执行 configure这个shell script 便可以产生合适的 Makefile 文件了。
使用 Makefile
利用 configure 所产生的 Makefile文件有几个预先设定的目标可供使用，这里只用几个简述如下：
make all = make
产生设定的目标，既范例中的可执行文件。只敲入make 也可以，此时会开始编译源代码，然后连接并产生执行文件。
make clean
清除之前所编译的可执行文件及目标文件(object file, *.o)。
make distclean
除了清除可执行文件和目标文件以外，也把 configure 所产生的 Makefile 清除掉。 通常在发布软件前执行该命令。
make install
将程序安装到系统中，若源码编译成功，且执行结果正确，便可以把程序安装到系统预先设定的执行文件存放路径中，若用 bin_PROGRAMS 宏的话，程序会被安装到 /usr/local/bin下。
make dist
将程序和相关的文档包装为一个压缩文档以供发布 (distribution) 。执行完在目录下会产生一个以
PACKAGE-VERSION.tar.gz 为名称的文件。PACKAGE 和 VERSION 这两个参数是根据 configure.in 文中AM_INIT_AUTOMAKE(PACKAGE, VERSION) 的定义。在我们的例子中会产生 'hello-1.0.tar.gz' 的文件。
make distcheck
和 make dist 类似，但是加入检查包装以后的压缩文件是否正常，这个目标除了把程序和相关文档包装成 tar.gz 文件外，还会自动把这个压缩文件解开，执行 configure，并执行 make all ，确认编译无错误以后，方显示这个 tar.gz 文件已经准备好并可以发布了。当你看到：
==========================================
hello-1.0.tar.gz is ready for distribution
==========================================
就可以放心地发布您的软件了，检查过关的套件，基本上可以给任何具备 GNU 开发环境的人去重新编译成功。
要注意的是，利用 Autoconf 及 Automake 所产生出來的软件套件是可以在没有安装 Autoconf 及 Automake 的环境使用的，因为 configure 是一个 shell script，它己被设计为可以在一般 Unix 的 sh 这个 shell 下执行。但是如果要修改 configure.in 及 Makefile.am 文件再产生新的 configure 及 Makefile.in 文件时就一定要有 Autoconf 及 Automake 了。
相关资料
通常我们掌握了一些入门知识就可以开始实践了，在有新的需求时，参照相关的文档和别人的例子解决问题，在实践中不断提高。
Autoconf 和 Automake 功能十分强大，可以从它们附带的 info 文档中找到详细的使用说明。或者您喜欢html,可以从gun站点上下载hmtl版本。你也可以从许多现有的GNU 软件或 Open Source 软件如Minigui中找到相关的 configure.in 或 Makefile.am 文件，他们是学习 Autoconf 及 Automake 更多技巧的最佳范例。
