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

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

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

之后，采用上面的配置文件信息進行測試的效果：

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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