全部學(xué)習(xí)匯總： GitHub - GreyZhang/g_SCons: A new member in my toolbox, looking forward to replacing make tool later.

我覺得SCons的應(yīng)用手冊(cè)的順序編排還是可以的，至少最前面的這部分編排是不錯(cuò)的。非常有助于一個(gè)了解過Makefile的人去做轉(zhuǎn)行的學(xué)習(xí)。前面實(shí)現(xiàn)了簡(jiǎn)單的單文件的編譯，這一次接下來至少先嘗試實(shí)現(xiàn)一下單目錄多文件的編譯了。在這次嘗試的過程中，暫且也忽略掉文件依賴的概念。

為了能夠?qū)崿F(xiàn)上面的例子，首先創(chuàng)建幾個(gè)代碼文件。為了能夠看看最終編譯的效果，我在file1.c和file2.c中放了一個(gè)pritnf，打印一下提示信息。然后，在prog.c的main函數(shù)中調(diào)用。

之后，采用上面的配置文件信息進(jìn)行測(cè)試的效果：

看得出來，構(gòu)建構(gòu)成。這里生成了一個(gè)叫做prog的可執(zhí)行文件，為什么叫這個(gè)名字呢？文檔中做了解釋，如果這個(gè)可執(zhí)行文件的名字沒有給出來具體的名稱，那么可執(zhí)行程序的名稱由文件列表中的第一個(gè)文件名稱決定。

同事，對(duì)于多文件（暫時(shí)考慮單目錄多文件的情況）的處理方法也給了說明，即創(chuàng)建一個(gè)列表，每一個(gè)文件都是列表中的一個(gè)字符串元素。

這樣的處理采用python來處理很容易，哪怕是SConstruct的文件中支持的Python特性不多，通過腳本來更新這個(gè)配置文件都是容易實(shí)現(xiàn)的。

這是指定可執(zhí)行文件名稱的方法，需要在Program的builder method中增加一個(gè)參數(shù)。按照上面的方式修改之后的測(cè)試效果：

能夠看得出來，可執(zhí)行文件的名稱被指定成功了。

這里又給出了一個(gè)使用通配符來實(shí)現(xiàn)的按照文件類別來處理的方法，這樣的方法在Makefile中也是有的。真是沒有，其實(shí)通過python腳本來輔助生成其他的信息也是很容易的。

這是采用通配符的方式實(shí)現(xiàn)的一個(gè)測(cè)試效果。

從這部分的講解看，SConstruct中的部分python支持處理還是可以的。自然，使用的時(shí)候得符合具體的使用規(guī)則。不過，類似列表的append處理或許時(shí)候不奏效？這一點(diǎn)從某些角度考慮是可以理解的，比如之前就已經(jīng)看到了這個(gè)SConstruct中的代碼執(zhí)行并不像python腳本一樣有著嚴(yán)格的執(zhí)行順序。不然，類似文件在列表中的追加或許一個(gè)append操作就可以了。

Split的應(yīng)用可以讓配置文件中的builder method的部分看上去更加簡(jiǎn)潔。不過，從自動(dòng)生成信息的角度來說的話，沒有看出什么特別的優(yōu)勢(shì)。只要是批處理容易實(shí)現(xiàn)，直接用腳本構(gòu)建SConstruct的時(shí)候可讀性，尤其是文件列表的可讀性就不是那么重要了。當(dāng)然，如果SConstruct是百分百的手工維護(hù)，這樣的精簡(jiǎn)風(fēng)格還是更有優(yōu)勢(shì)的。

這里的參數(shù)用法相比前面的表述方式更有可讀性上的提高，尤其是對(duì)于初步接觸的人來說更有優(yōu)勢(shì)。然而，這個(gè)地方一共就有2個(gè)參數(shù)的時(shí)候，在熟練之后這種可讀性的優(yōu)勢(shì)也就微乎其微了。

綜合看來，在整體的可讀性以及維護(hù)性上，相比老牌的Makefile方案scons的確還是有一點(diǎn)優(yōu)勢(shì)的。但是接下來的嘗試才具有真正的工程管理的意義，至少我得能夠用這個(gè)優(yōu)雅地處理各種文件文件的依賴關(guān)系以及復(fù)雜的文件目錄結(jié)構(gòu)才能夠讓這個(gè)工具具備真正的生產(chǎn)力加速的效果。

總結(jié)

以上是生活随笔為你收集整理的1222_SCons单目录多文件的编译实现的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。