引用私有程序
不要在任何情況下，為你在的GNU中的工作或者在工作中引用Unix的源代碼（或者任何其它私有程序）。如果你對一個Unix程序內(nèi)容有一些模糊的記憶，這并不因為著你絕對寫程序來模仿它，但請試圖在內(nèi)部使用不同的代碼行來組織它，因為這將使你工作的結(jié)果在細節(jié)上與Unix版本有所不同。例如，Unix工具通常進行了優(yōu)化以使用最少的內(nèi)存；如果你更希望提高速度，你的程序?qū)泻艽蟮牟煌?。你可以在?nèi)核中保存整個輸入文件并且在內(nèi)存中掃描而不是使用stdio。
使用比Unix程序更新的、更明智的算法。不使用暫時文件。在一遍掃描而不是兩遍掃描中完成任務（我在assembler（匯編器）中這樣做了）。或者相反，強調(diào)簡單性而不是速度。對于一些應用程序來說，今天的計算機只要使用簡單的算法就夠了。或者注重一般性。例如，Unix程序通常使用靜態(tài)的表格和固定大小的字符串，這導致了不可改變的限制；用動態(tài)分配來代替。確認你的程序處理了輸入文件為空和其它滑稽的情況。為增加擴展性而增加一種程序語言并且用那種語言完成程序的一個部分?；蛘甙殉绦虻囊徊糠中薷某瑟毩⒌膸??；蛘哂靡粋€簡單的廢物收集器而不是在釋放內(nèi)存的時候精確地進行跟蹤，
或者使用諸如obstacks這樣的新的GNU工具。

接受他人的奉獻
如果其他人發(fā)給你一段添加到你正在編寫程序中的代碼，我們需要準許使用它的法律文書——我們將需要從你那里取得同樣的法律文書。程序的每個重要的貢獻者都必須簽署
某種法律文書以使得我們可以給程序一個清晰的標題。僅有主要作者是不夠的。所以，在把來自于他人的任何共享添加到程序中之前，告訴我們以便我們可以做出安排以獲取文書。在你實際地使用貢獻之前，請等待直到我們告訴你我們已經(jīng)收到了簽署的文書。這即適用于你發(fā)行程序之前也適用于發(fā)行之后。如果你收到了一個修正bug的補丁，并且它們做了主要的修改，我們就需要為他提供法律文書。
你不需要為這里或者那里的少數(shù)幾行修改提供文書，因為對于達到版權(quán)目的沒有意義。還有，如果你從建議中獲得的僅僅是一些想法，而不是你實際上使用的代碼，你也不需要文書。例如，如果你寫了一個程序的不同解決方案，你并不需要獲得許可文書。
我知道這是十分麻煩的；它對我們來說也十分麻煩。但如果你不等待，你就可能誤入歧途，如果這個貢獻者的雇主不肯簽署棄權(quán)聲明怎么辦？你可能不得不再次把代碼剔除出來！最糟糕的情況是如果你忘記告訴我們其它的貢獻者，我們可能會因此而窘迫地出現(xiàn)在法庭上。

修改日志
為每個目錄維護一個修改日志，以記述對這個目錄下源文件的修改。這樣做的目的是使得在將來尋找bug的人可以指導大致是那些修改導致了錯誤。通常，一個新的bug可以在最近進行的修改中被找到。更重要的事，修改日志有助于消除程序的不同部分之間在概念上的不一致性；它們可以告訴我們概念沖突產(chǎn)生的歷史。使用Emacs命令M-x add-change在修改日之中創(chuàng)建一個新的條目。一個條目應該包含一個星號、被修改的文件的名稱以及被擴在括號內(nèi)的、被修改了的函數(shù)、變量或者任何東西。括號之后是冒號和對你對函數(shù)或變量的修改的說明。
用空行把無關(guān)的條目分隔開。如果兩個條目反映了同一個修改，因而它們一同工作，那就不要在它們之間使用空行。如果后續(xù)的條目針對的是相同的文件，那么你可以忽略文件名的星號。下面是一些例子：
* register.el (insert-register): Return nil.(jump-to-register): Likewise.* sort.el (sort-subr): Return nil.* tex-mode.el (tex-bibtex-file, tex-file, tex-region):Restart the tex shell if process is gone or stopped.(tex-shell-running): New function.* expr.c (store_one_arg): Round size up for move_block_to_reg.(expand_call): Round up when emitting USE insns.* stmt.c (assign_parms): Round size up for move_block_from_reg.
在這里沒有必要敘述修改的完整目錄和它們是如何協(xié)同工作的。把這些說明作為注釋放到代碼中更好一些。這就是說為什么只要給出“New function”就夠了；在源代碼中，與函數(shù)放在一起的注釋說明了它是做什么的。然而，有時為一大堆修改寫上一行文字以描述它們的整體目的是有用的。
在概念上，你可以把修改日志看作解釋原始版本與當前版本的不同的“undo列表”。
人們可以閱讀當前的版本；他們不需要修改日志告訴他們其中有什么。他們從修改日之中
得到的是關(guān)于早期版本的不同的清晰解釋。在你以簡單的方式修改函數(shù)的調(diào)用順序，并且你修改了所有對函數(shù)的調(diào)用時，不必為所有的調(diào)用創(chuàng)建單獨的條目。只要在被調(diào)用的函數(shù)的條目中寫“All callers changed.”即可。在你僅僅修改了注釋或者文檔字符串的時候，為該文件寫一個條目，而不必提到函數(shù)，就足夠了。只要寫"Doc fix."。不必為文檔文件維護修改日志。這是因為文檔不那么容易受到難以修正的錯誤的影響。文檔不是由那些必須以精確地工程方式相互作用的部分組成的；要修改一個錯誤，你不需要知道這個錯誤傳播的歷史。
與其它實現(xiàn)的兼容性
作為一個特例，對于GNU中的工具程序和庫，它們應該和Berkeley Unix相應的部分向上兼容，如果標準C定義了它們的行為，那它們應該和標準C向上兼容，如果POSIX規(guī)范定義了它們的行為，那它們也應該與POSIX規(guī)范向上兼容。當這些標準發(fā)生沖突的時候，為每個標準提供兼容模式是有用的。標準C和POSIX禁止進行任何形式的擴展。自由地進行你的擴展，并且把選‘-ansi’或‘-compatible’包括進來以關(guān)閉你的擴展。但是如果擴展很可能導致任何實際程序或者腳本的崩潰，那么它可能實際上不是向上兼容的。嘗試一下重新定義它的界面。
當一個特征僅僅被用戶（而不會被程序或者命令文件）所使用的時候，并且在Unix中它完成得并不好，請自由地用完全不同并且更好的方式代替它。（例如，用Emacs代替vi。）但同時提供兼容模式仍然是很好的。（現(xiàn)在有自由的vi實現(xiàn)，所以我們提供了它。）歡迎提供Berkeley Unix沒有提供的有用功能。Unix中沒有的附加功能可能是有用的，但我們優(yōu)先復制那些Unix已經(jīng)有的功能。

Makefile慣例
本章敘述為GNU程序書寫Makefile的慣例。
Makefile的通用慣例
每個Makefile都應該包含這一行：SHELL = /bin/sh
以避免那些由從環(huán)境中繼承SHELL變量的系統(tǒng)帶來的麻煩。（GNU make永遠不會出現(xiàn)這個問題。）不要假定‘.’出現(xiàn)在用于尋找可執(zhí)行的命令的路徑中。當你需要在make期間運行作為你的包的一部分的程序時，如果程序是作為make的一部分而創(chuàng)建的，請確保它使用了‘./’，或者如果文件是不會被改變的源代碼的一部分，請確保它使用了‘’$(srcdir)/’。
如果運行‘configure’時使用了選項‘-srcdir’，那么‘./’與‘$(srcdir)/’之間的區(qū)別就十分重要。一下形式的規(guī)則：
foo.1 : foo.man sedscript        sed -e sedscript foo.man > foo.1
將在當前目錄不是源代碼目錄的情況下導致錯誤，這是因為‘foo.man’和‘sedscript’不在當前目錄中。在使用GNU make的時候，由于不論源文件在那里，‘make’的自動變量‘$<‘
都將表示它，所以在只存在一個依賴文件的情況下，依靠‘VPATH’來尋找源文件仍然是可行的。（許多版本的make只在隱含規(guī)則中設置‘$<‘。）如下的makefile目標：
foo.o : bar.c        $(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o
將被如下目標所替代：
foo.o : bar.c        $(CC) $(CFLAGS) $< -o $@
以便使’VPATH’能夠正確地工作。當目標含有多的依賴文件時，顯式地使用‘$(srcdir)’讓規(guī)則正常工作的最簡單辦法。例如，上述為‘foo.1’而提供的目標最好被寫作：
foo.1 : foo.man sedscript        sed -s $(srcdir)/sedscript $(srcdir)/foo.man > foo.1
Makefile中的工具
書寫能夠在sh，而不是在csh，中運行的Makefile命令（以及任何shell腳本，例如
configure）。不要使用任何ksh或者bash特殊的功能。為創(chuàng)建和安裝而提供的configure腳本和Makefile規(guī)則不要直接使用任何工具，除了以下的幾個之外：
cat cmp cp echo egrep expr grepln mkdir mv pwd rm rmdir sed test touch
堅持使用這些程序通常支持的選項。例如，因為許多系統(tǒng)不支持‘mkdir -p’，盡管它可能有些方便，但不要使用它。
為創(chuàng)建和安裝而提供的Makefile規(guī)則還可以使用編譯器和相關(guān)的程序，但應該通過make變量以便用戶對它們進行替換。下面是一些我們所說的相關(guān)的程序：
ar bison cc flex install ld lexmake makeinfo ranlib texi2dvi yacc
在你使用ranlib的時候，你應該測試它是否存在，并且僅僅在它存在的情況下運行它，以使得發(fā)布版本在那些沒有ranlib的系統(tǒng)中也能夠工作。如果你使用了符號連接，你應該為沒有符號連接的系統(tǒng)實現(xiàn)一個替代手段。你可以在只打算用于特定系統(tǒng)的Makefile的部分（或者腳本）中使用你能夠確認在那些系統(tǒng)上存在的工具。

為用戶提供的標準目標
所有的GNU程序應該在它們的Makefile中含有下列目標：
‘all’
編譯整個程序。它應該是缺省目標。這個目標不需要重新創(chuàng)建任何文檔文件；Info文件被包含在發(fā)布版本中，同時，只有在用戶明確地要求創(chuàng)建DVI文件的時候才創(chuàng)建DVI文件。
‘install’
編譯程序并且把可執(zhí)行文件、庫文件等文件復制到它們在實際應用中應該存在的位置。如果存在一個可以檢測程序是否被正確地安裝了的簡單測試，本目標將首先運行這個測試。如果文件的安裝目錄不存在，該命令將創(chuàng)建這樣的目錄。它們包括由變量prefix和exec_prefix的值指明的目錄，以及需要的所有目錄。完成該任務的一種方式是按照后面所說明的方式通過目標installdirs來完成。在任何用戶安裝man手冊的命令之前使用‘-’，以使得make忽略所有的錯誤。錯誤將在那些沒有安裝Unix man手冊文檔系統(tǒng)的系統(tǒng)中出現(xiàn)。
安裝Info文件的方式是用$(INSTALL_DATA)把它們復制到‘$(infodir)’中。（參見為指明命令而提供的變量），并且如果有程序install-info存在，那么就運行它。install-info是一個腳本，它編輯Info ‘dir’文件以把給定的Info文件添加或者更新目錄項的腳本；它將是Texinfo包的一個部分。下面是用于安裝一個Info文件一個簡單規(guī)則：
$(infodir)/foo.info: foo.info# There may be a newer info file in . than in srcdir.        -if test -f foo.info; then d=.; \         else d=$(srcdir); fi; \        $(INSTALL_DATA) $$d/foo.info $@; \# Run install-info only if it exists.# Use ‘if’ instead of just prepending ‘-’ to the# line so we notice real errors from install-info.# We use ‘$(SHELL) -c’ because some shells do not# fail gracefully when there is an unknown command.        if $(SHELL) -c ‘install-info --version’ \           >/dev/null 2>&1; then \          install-info --infodir=$(infodir) $$d/foo.info; \        else true; fi
‘uninstall’
刪除所有由’install’目標創(chuàng)建的所有安裝的文件（但不包括那些由諸如’make all’之類的目標創(chuàng)建的，沒有被安裝的文件）。
‘clean’
從當前目錄中刪除所有在創(chuàng)建程序過程中創(chuàng)建的文件。不要刪除那些紀錄配置情況的文件。有些文件可能是在創(chuàng)建過程中創(chuàng)建的，但因為它們是和發(fā)布版本一起發(fā)布的，通常不是在創(chuàng)建過程中創(chuàng)建的，這樣的文件也需要保留下來。如果‘.dvi’文件不是發(fā)布版本的一部分，就刪除它們。
‘distclean’
從當前目錄中刪除所有在程序的配置和創(chuàng)建過程中創(chuàng)建的文件。如果你解包源代碼并且在沒有添加任何其它文件的情況下創(chuàng)建程序，‘make distclean’將僅僅保留那些出現(xiàn)在發(fā)布版本中的文件。
‘mostlyclean’
類似于‘clean’，可能不會刪除少數(shù)人們通常不希望重新編譯的文件。例如，GCC的
‘mostlyclean’目標不會刪除‘libgcc.a’，這是因為很少需要重新編譯并且重新編譯將花費大量的時間。
‘realclean’
從當前目錄中刪除所有可以由Makefile重新創(chuàng)建的文件。這通常包括所有由distclean刪除的文件，以及：由Bison生成的C源文件、標記表（tags tables）、Info文件等等。然而有一個例外：即使‘onfigure’以通過使用Makefile中的規(guī)則重新創(chuàng)建，‘ake realclean’也不會刪除‘onfigure’更一般地說，‘ake realclean’不會刪除為了運行‘onfigure’而存在的任何東西，并且隨后開始創(chuàng)建程序。
‘AGS’
為本程序更新標記表（tags table）。
‘nfo’
生成所有需要的Info文件。書寫該規(guī)則的最佳方式是：
info: foo.infofoo.info: foo.texi chap1.texi chap2.texi        $(MAKEINFO) $(srcdir)/foo.texi
你必須在Makefile中定義變量MAKEINFO。它應該運行程序makeinfo，該程序是Texinfo發(fā)布版本的一部分。
‘vi’
為所有Xinfo文檔VI文件，比如：
dvi: foo.dvifoo.dvi: foo.texi chap1.texi chap2.texi        $(TEXI2DVI) $(srcdir)/foo.texi
你必須在Makefile中定義變量TEXI2DVI。它應該運行程序texi2dvi，該程序也是Texinfo
發(fā)布版本的一部分。作為另一個選擇，只要寫依賴文件并且允許GNU Make提供這個命令就行了。
‘ist’
為本程序創(chuàng)建一個發(fā)布版本tar文件。該tar文件將被設置以使得在tar文件中的文件名以子目錄名開頭，這個子目錄名是包用于發(fā)布的名字。這個名字可以包含版本號。例如，GCC版本1.40的發(fā)布tar文件將被解包到名為’gcc-1.40’的子目錄中。完成該任務的最簡單方式是以適當?shù)拿Q創(chuàng)建一個子目錄，使用ln或者cp把正確的文件安裝到該目錄中，而后tar這個子目錄。目標dist應該顯式地依賴于發(fā)布版本中所有的非源文件，以確保它們在發(fā)布版本中都不是過時的。參見制作發(fā)布包
‘heck’
（如果有的話）執(zhí)行自檢測。用戶必須在運行測試之前，但不必在安裝程序之前創(chuàng)建程序；你應該寫下自檢測以便它們在程序創(chuàng)建之后而沒有被安裝之前進行工作。對于那些適用于以下的目標的程序，建議你按照常用的名字提供它們。
‘nstallcheck’
（如果有的話）執(zhí)行安裝監(jiān)測。用戶必須在運行該檢測之前創(chuàng)建并且安裝程序。你不應該假定’(bindir)’出現(xiàn)在搜索路徑中。
‘nstalldirs’
添加一個名為‘installdirs’的目標，以便創(chuàng)建安裝文件的目錄和它們的父目錄。有一個稱為‘mkinstalldirs’的腳本可以為此提供便利；在Texinfo包中可以找到它。你可以使用象下面那樣的規(guī)則：
# Make sure all installation directories (e.g. $(bindir))# actually exist by making them if necessary.installdirs: mkinstalldirs        $(srcdir)/mkinstalldirs $(bindir) $(datadir) \                                $(libdir) $(infodir) \                                $(mandir)

為指明命令而提供的變量
Makefile應該提供變量以覆蓋某些命令、選項等等。特別地，你應該通過變量來運行大部分工具程序。因此，如果你使用了Bison，就定義一個缺省值是通過’BISON = bison’來設定的變量BISON，并且在你需要使用Bison的所有地方通過$(BISON)引用它。在這種方式下，文件管理工具：ln、rm、mv等等并不需要通過變量引用，這是因為用戶不需要用其它程序來替代它們。每個程序名變量都應該有一個對應的變量以便為程序提供選項。把’FLAGS’附加到程序名變量名的后面就是選項變量名--例如，BISONFLAGS。（名字CFLAGS是這項規(guī)則的一個例外，但因為它是標準的而保留了它。）在任何運行預處理器的編譯命令中使用CPPFLAGS，在任何進行連接的編譯命令和任何對ld的直接使用中使用LDFLAGS。
如果存在一些為了正確地編譯某些文件而必須使用的C編譯器選項，不要把它們包括在CFLAGS中。用戶希望能夠自由地指明CFLAGS的值。替代的方式是：通過在編譯命令行中顯式地給出這些必要的選項或者通過定義一條隱含規(guī)則，從而以獨立于CFLAGS的方式把選項傳遞給C編譯器。
CFLAGS = -gALL_CFLAGS = -I. $(CFLAGS).c.o:        $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
把選項‘-g’包括在CFLAGS中，因為它對于正確的編譯來說并不是必要的。你可以認為它僅僅是關(guān)于缺省值的一個建議。如果包被設置成在缺省的狀態(tài)下由GCC編譯，那么你可能還需要把‘-O’包括在CFLAGS的缺省值之中。
把CFLAGS放在編譯命令行的最后，就是在其它包含了編譯選項的變量之后，以便于用戶使用CFLAGS來覆蓋其它的選項。每個Makefile都應該定義變量INSTALL，它是把一個文件安裝到系統(tǒng)中的基本命令。每個Makefile還應該定義變量INSTALL_PROGRAM和INSTALL_DATA。（兩者的缺省值都應該是$(INSTALL)。）而后，Makefile應該使用這些變量作為實際安裝的命令，分別用于安裝可執(zhí)行文件和不可執(zhí)行的文件。按照下面的方式使用這些變量：
$(INSTALL_PROGRAM) foo $(bindir)/foo$(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a
總是把文件名，而不是目錄名，作為安裝命令的第二個參數(shù)。為每個需要安裝的文件使用獨立的命令。

為安裝目錄而提供的變量
安裝目錄總是應該通過變量來命名，以易于把包安裝在其它非標準的位置。這些變量的標準名字是：
‘prefix’
用于構(gòu)造下列變量的缺省值的前綴。prefix的缺省值應該是‘/usr/local’（至少現(xiàn)在是它）。‘exec_prefix’’
用于構(gòu)造下列某些變量的缺省值的前綴。exec_prefix的缺省值應該是$(prefix)。一般來說，$(exec_prefix)指的是用于儲存與機器有關(guān)的文件（比如說可執(zhí)行文件和子程序庫）的目錄，而$(prefix)則被直接用于其它目錄。
‘bindir’
用于儲存用戶可以運行的可執(zhí)行程序的目錄。一般來說應該是‘/usr/local/bin’，但應該被寫作‘$(exec_prefix)/bin’。
‘libdir’
用于安裝由程序運行，而不是由用戶運行的可執(zhí)行文件的目錄。Object文件和object代碼庫也應該被儲存在這個目錄。提供該目錄的意圖是為了儲存適用于特殊機器結(jié)構(gòu)，但又不必出現(xiàn)在命令路徑中的文件。libdir的值通常是‘/usr/local/lib’，但應該被寫作‘$(exec_prefix)/lib’。
‘datadir’
用于安裝程序在運行時需要訪問的只讀數(shù)據(jù)文件的目錄。該目錄用于儲存與使用的機器獨立的文件。它通常是‘/usr/local/lib’，但應該被寫作‘$(prefix)/lib’。
‘statedir’
用于安裝程序在運行時需要修改的數(shù)據(jù)文件的%9