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

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

為了能夠實現上面的例子，首先創建幾個代碼文件。為了能夠看看最終編譯的效果，我在file1.c和file2.c中放了一個pritnf，打印一下提示信息。然后，在prog.c的main函數中調用。

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

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

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

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

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

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

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

這是采用通配符的方式實現的一個測試效果。

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

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。