［翻译］LFS重要参考文档－GNU编码标准第7章 发布过程

地球发动机

发布一个软件不仅仅是从源代码构建出一个tar文件并把它放到FTP服务起上。你应该将软件配置为可以在许多系统上运行。你的Makefile应当遵循下文所述的GNU标准，安装目录结构也要符合下文的标准。这样，在GNU软件这个更大的框架中包含进你的软件报就会很容易。

7.1 配置应该如何运作
每个GNU软件发布时都带有一个名为configure的shell脚本。这个脚本接收一些参数，用来描述编译程序的机器和系统的类型。

这个configure脚本必须记录用以影响编译过程的配置选项。

为此，有一种方法是把一些标准的文件名如config.h链接到为适合于所选机器的特定配置文件上。如果你采用了这种技术，发布版本不应包括config.h文件。这样人们就不会在没有配置的情况下构建程序。

configure可以做的另一件事情是编辑Makefile。如果需要这样做，发布版本不应该含有Makefile文件，而应该含有Makefile.in文件，让它包含需要编辑的内容。同样，这样就能避免别人在没有配置的情况下进行构建。

如果configure 需要写入Makefile，那么Makefile要有一个名为“Makefile”的目标，它会让configure重新运行，用和上次运行一样的设置进行配置。configure脚本所需要读取的文件应该作为依赖项目在Makefile中列出。

configure脚本所有的输出文件应该在开头加上注释，声明这些文件是由configure自动生成的。这样用户就不会想要手工编辑它们。

configure脚本应该输出一个名为config.status的文件，描述最后一次配置的时候有些什么配置选项被采纳了。这个文件本身应该是一个shell脚本，当运行的时候，能产生同样的配置。

configure脚本应该接收形如“--srcdir=dirname"的选项，以指定包含源代码的目录所在（如果它不在当前目录下）。这样就可以在另一个目录下构建程序，以免真正的源代码目录被更改。

如果用户没有指定--srcdir，configure应该同时检查.和..这两个目录，看是否能发现源代码。如果它在这些位置发现了源代码，就应该在那里使用它。否则，它应该报告无法发现源代码的错误，并以非零的状态码退出。

通常的简单实现--srcdir的方法是在Makefile里面修改VPATH变量的值。为了让用户明确指定源代码的位置，需要使用一些规则。为了实现这些，configure可以把srcdir变量添加到Makefile里面，而它的值就指向用户指定的位置。

另外，configure脚本应该接收表示标准目录的许多变量（参考7.2.5[目录变量]）。这里是其列表：

1. 
   
2. --prefix --exec-prefix --bindir --sbindir --libexecdir --sysconfdir
   
3. --sharedstatedir --localstatedir --libdir --includedir --oldincludedir
   
4. --datarootdir --datadir --infodir --localedir --mandir --docdir
   
5. --htmldir --dvidir --pdfdir --psdir
   

复制代码

configure 脚本也应该获取表示在其上构建程序的机器的参数。该参数应该像这样子：

1. 
   
2. cpu-company-system
   

复制代码

例如，基于Athlon的GNU/Linux系统可能是“i686-pc-linux-gnu"

configure脚本需要对所有可能的别名进行解码。例如，athlon-pc-gnu/linux应该是一个合法的别名。你可以使用名为config.sub的脚本作为例程来校验系统类别及其别名。

configure脚本应该接收形如--build=buildtype的参数，这个和单纯给出buildtype作为参数应该是等价的。例如，configure --build=i686-pc-linux-gnu和configure i686-pc-linux-gnu是等价的。如果构建系统类别没有给出，configure脚本通常应该用config.guess进行猜测。

[待续]

1987a

不太明白lz给出上面翻译的用意。

这里是原文 http://www.gnu.org/prep/standards/
这里有翻译好的全文 http://www.huihoo.org/code/gnu_code.html

已有的翻译过时了？
lz还在努力使用gcc独立build目录的方式编译整个系统？

地球发动机

Post by 1987a;1852949
不太明白lz给出上面翻译的用意。

这里是原文 http://www.gnu.org/prep/standards/
这里有翻译好的全文 http://www.huihoo.org/code/gnu_code.html

已有的翻译过时了？
lz还在努力使用gcc独立build目录的方式编译整个系统？

已有翻译确实过时了。现在的原文比你给出的译文多了不是一点点。原来的编码规范对LFS用处不是很大，毕竟主要是指导程序员的。但是现在的文档第7章介绍了configure的各种参数，并且给出详细解释，这个应该对LFS帮助很大。

我这段时间升级Ubuntu至8.04，还在适应中。应该很快就会重开LFS的研究了。

1987a

Post by 地球发动机;1852957
已有翻译确实过时了。现在的原文比你给出的译文多了不是一点点。原来的编码规范对LFS用处不是很大，毕竟主要是指导程序员的。但是现在的文档第7章介绍了configure的各种参数，并且给出详细解释，这个应该对LFS帮助很大。

我这段时间升级Ubuntu至8.04，还在适应中。应该很快就会重开LFS的研究了。

如果只是配置编译的话，对符合GNU标准的软件包 ./configure --help 给出的提示信息足够了。
如果是开发者，GNU标准工具 autoconf automake make 熟悉后，基本就可以做到符合GNU编码标准。

多谢 lz 共享资源。

地球发动机

Post by 1987a;1852965
如果只是配置编译的话，对符合GNU标准的软件包 ./configure --help 给出的提示信息足够了。
如果是开发者，GNU标准工具 autoconf automake make 熟悉后，基本就可以做到符合GNU编码标准。

多谢 lz 共享资源。

有一点很重要的，这个编码标准指出了一个标准GNU发布版的脚本应该依赖的程序列表。这个列表是LFS工具链软件包选择的依据！所以我说这个文档还是很重要的。

1987a

Post by 地球发动机;1852976
有一点很重要的，这个编码标准指出了一个标准GNU发布版的脚本应该依赖的程序列表。这个列表是LFS工具链软件包选择的依据！所以我说这个文档还是很重要的。

不完全是这样，我们反过来分析好了：
我们建立自己的系统，最重要的是使自己的 GNU/Linux 系统自举，即拥有启动和自扩展能力；（为说明方便，下面我们称这个系统为系统A）
系统A的最小集合包括 linux内核、一个shell、工具链、一个编辑器；
系统A应当有能力完成另一个系统A的自举，既有能力编译最小集合列出的所有软件包，根据软件包配置、编译、安装时的依赖关系，lz提到的程序被包括在系统A中，另外perl（非GNU工具）也被包括在系统A中；
此外，为方便使用管理系统A，我们加入init进程，加入登录机制，加入udev（可选），加入bootloader（可选），加入分区及建立文件系统的工具，加入网络配置管理工具；
至此系统A诞生，最后得到的系统A软件包列表与 CLFS/LFS方法 给出的软件列表应该没有太大出入。

地球发动机

Post by 1987a;1853011
不完全是这样，我们反过来分析好了：
我们建立自己的系统，最重要的是使自己的 GNU/Linux 系统自举，即拥有启动和自扩展能力；（为说明方便，下面我们称这个系统为系统A）
系统A的最小集合包括 linux内核、一个shell、工具链、一个编辑器；
系统A应当有能力完成另一个系统A的自举，既有能力编译最小集合列出的所有软件包，根据软件包配置、编译、安装时的依赖关系，lz提到的程序被包括在系统A中，另外perl（非GNU工具）也被包括在系统A中；
此外，为方便使用管理系统A，我们加入init进程，加入登录机制，加入udev（可选），加入bootloader（可选），加入分区及建立文件系统的工具，加入网络配置管理工具；
至此系统A诞生，最后得到的系统A软件包列表与 CLFS/LFS方法 给出的软件列表应该没有太大出入。

按照我的标准，你这个系统还是太大。

一个最小系统根本不需要内核，只要能chroot进去并完成其它软件的编译安装，即可。这个最小系统基本上等价于LFS中tools目录工具链的软件列表。

这个相当于当年gentoo的stage1：一个能chroot进去并完成bootstrap的完整二进制包。我正在致力于完成这样一个包，此后可以以此包为基础，在任何Linux系统上，只要能chroot，就一定能以可预测的方式完成LFS，而无论宿主机上是否安装有相关软件。这样就能把对宿主的要求降到最低！

1987a

Post by 地球发动机;1853027
按照我的标准，你这个系统还是太大。

一个最小系统根本不需要内核，只要能chroot进去并完成其它软件的编译安装，即可。这个最小系统基本上等价于LFS中tools目录工具链的软件列表。

按我的标准，你的最小系统应称为最小rootfs。

Post by 地球发动机;1853027
  这个相当于当年gentoo的stage1：一个能chroot进去并完成bootstrap的完整二进制包。我正在致力于完成这样一个包，此后可以以此包为基础，在任何Linux系统上，只要能chroot，就一定能以可预测的方式完成LFS，而无论宿主机上是否安装有相关软件。这样就能把对宿主的要求降到最低！

这里有点小问题：
如果，宿主内核是x86_64的，并打开32bit兼容支持，而你的stage1是以i686方式编译的，那么，chroot到stage1是成功的；但编译gcc时会出错，应以"linux32 chroot ……"的方式进入你的stage1才能正常编译。

对gentoo没什么经验，只是玩过stage3+portage，portage中用于建立stage1的脚本扫过几眼，不是太明白stage1的建立过程，莫非gentoo使用类似LFS的方式建立stage1？

地球发动机

Post by 1987a;1853076
按我的标准，你的最小系统应称为最小rootfs。



这里有点小问题：
如果，宿主内核是x86_64的，并打开32bit兼容支持，而你的stage1是以i686方式编译的，那么，chroot到stage1是成功的；但编译gcc时会出错，应以"linux32 chroot ……"的方式进入你的stage1才能正常编译。

这个不是问题。按照定义，从x86_64到i686的build属于交叉编译，因此应该使用For CLFS的方式编译。而如果用了CLFS的方式，也就不需要linux32了吧。

Post by 1987a;1853076

对gentoo没什么经验，只是玩过stage3+portage，portage中用于建立stage1的脚本扫过几眼，不是太明白stage1的建立过程，莫非gentoo使用类似LFS的方式建立stage1？

在gentoo stage1下，运行bootstrap.sh脚本将会编译工具链3次，以确保所有的代码都是原生编译。stage1是预先建立的一个二进制打包文件，里面仅含有足够进行chroot和bootstrap的软件。

从stage1到stage3的流程如下：
stage1: bootstrap.sh -> stage2 : emerge -e system -> stage3

1987a

Post by 地球发动机;1853242
这个不是问题。按照定义，从x86_64到i686的build属于交叉编译，因此应该使用For CLFS的方式编译。而如果用了CLFS的方式，也就不需要linux32了吧。

你的前提是能chroot即可，上面的特殊情况真实存在，比如我们想在x86_64硬件环境安装i686-pc-linux-gnu的系统。
那种情况下编译gcc失败，是因为gcc自动测试是否起用交叉编译，而我们要的是本地编译；编译sed就不会出现问题。
你如果坚持CLFS也可以，只是又退回去罢了。

Post by 地球发动机;1853242
  在gentoo stage1下，运行bootstrap.sh脚本将会编译工具链3次，以确保所有的代码都是原生编译。stage1是预先建立的一个二进制打包文件，里面仅含有足够进行chroot和bootstrap的软件。

从stage1到stage3的流程如下：
stage1: bootstrap.sh -> stage2 : emerge -e system -> stage3

看来理解错gentoo的bootstrap.sh了。

跑题了。