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
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
