C++ Coding Standards Item 2 : Use an automated build system
http://spaces.msn.com/members/spiritauding/Blog/cns!1psm74keJLzaQ6CnZ_EB1mAw!125.entry
C++ Coding Standards Item 2 : Use an automated build system
Summary
Push the (singular) button: Use a fully automatic ("one-action") build system that builds the whole project without user intervention.
按一个按钮：使用一个完全自动的编译系统，可以编译整个工程而不需要用户参与。
Discussion
A one-action build process is essential. It must produce a dependable and repeatable translation of your source files into a deliverable package. There is a broad range of automated build tools available, and no excuse not to use one. Pick one. Use it.
只用一次动作就可完成编译的过程是很有效率的。它可以独立的、可重复的把你的源代码转换成可以发布的软件包。现在有很多自动编译的工具可以选择，我们没有理由不使用，所以选择一个，然后使用。
We've seen organizations that neglect the "one-action" requirement. Some consider that a few mouse clicks here and there, running some utilities to register COM/CORBA servers, and copying some files by hand constitute a reasonable build process. But you don't have time and energy to waste on something a machine can do faster and better. You need a one-action build that is automated and dependable
我们看到过一些组织忽略了这种“一次动作”的需求。他们认为用鼠标到处点点，运行一些工具注册COM/CORBA服务器，然后手工拷贝一些文件，这就是编译过程。但是你没有那么多时间和精力，可以浪费在一件机器可以做的更快、更好的事情上。你真的需要一次动作的编译，它是自动的并且是独立的。
Successful builds should be silent, warning-free (see Item 1). The ideal build produces no noise and only one log message: "Build succeeded."
如Item 1所述 ，成功的编译应该是安静的，没有任何警告信息的。理想的编译过程应该只有一条信息："Build succeeded."
Have two build modes: Incremental and full. An incremental build rebuilds only what has changed since the last incremental or full build. Corollary: The second of two successive incremental builds should not write any output files; if it does, you probably have a dependency cycle (see Item 22), or your build system performs unnecessary operations (e.g., writes spurious temporary files just to discard them).
有两种编译模式：增长式和完全式。增长式编译只是重新编译那些上次编译之后更改过的内容。必然结果：连续两次的增长式编译的第二次应该没有任何输出文件；如果有，那么可能有依赖环存在，或者你的编译系统作了一些不必要的操作（例，写一些假的临时文件，可以忽略）
A project can have different forms of full build. Consider parameterizing your build by a number of essential features; likely candidates are target architecture, debug vs. release, and breadth (essential files vs. all files vs. full installer). One build setting can create the product's essential executables and libraries, another might also create ancillary files, and a full-fledged build might create an installer that comprises all your files, third-party redistributables, and installation code.
一个项目可以有不同形式的完全编译。可以考虑根据不同的编译特点，设定编译参数；例如target architecture, debug vs. release, and breadth（基本文件，全部的文件，完全安装）。一个编译设置可以产生可执行文件和库文件，也可能产生一些辅助文件，一个非常完整的编译可能生成安装文件，包含了全部的需要的文件，第三方的发布包，和安装代码。
As projects grow over time, so does the cost of not having an automated build. If you don't use one from the start, you will waste time and resources. Worse still, by the time the need for an automated build becomes overwhelming, you will be under more pressure than at the start of the project.
随着时间的推移，项目会不断增长，如果没有一个自动编译工具，那编译的代价也会越来越大。如果从项目的开始就没有使用自动编译工具，那一定会浪费很多时间和资源。更糟的是，当迫切的需要引入自动编译的时候，你将承受比项目刚刚开始的时候更大的压力。
Large projects might have a "build master" whose job is to care for the build system
大项目应该有一个“编译员”，他的工作就是认真地编译系统。
这一章讲自动编译的好处，呵呵，好处很容易理解，但是使用起来就有困难了，我们现在的工作：每次发布之前，要统一修改全部文件的时间戳（不理解，我觉得文件的创建时间对它里面内容没有任何帮助），挪到一台专用机器上编译，这是可以接受的，但是不可以修改生成文件的路径，要手动把生成的文件拷贝到指定目录（变态的做法，还好我现在不是那个“编译员”），然后再打包、上传。日本人如果一件事情做熟了就会义无反顾的坚持下去，直到领导下令改变，否则雷打不动，我也向他们学习，坚持着不去优化这个过程，任何过程。
Copy Left (C) Scorpio Auding 2005-11-24
