1

我有在頂級目標需要多個vmlinux的二進制文件(Linux內核)作爲先決條件的美容基礎的項目,所以它看起來是這樣的:如何到目標依賴於多個Linux佈局的Makefile建立

all: bigfile 
bigfile: bigfile.cfg a/vmlinux b/vmlinux c/vmlinux foo bar baz 
    sometool -obigfile -ibigfile.cfg # other inputs referenced from within the config 

和每個Linux規則看起來或多或少像:

a/vmlinux: a/.config 
    $(MAKE) -C $(A_LINUX_SRC) O=$(PWD)/a vmlinux 
a/.config 
    mkdir -p a 
    $(MAKE) -C $(A_LINUX_SRC) O=$(PWD)/a $(A_LINUX_DEFCONFIG) 

類似地,對於b和C的Linux內核。注意每個可能有相同或不同的源代碼樹,並且幾乎肯定會有不同的defconfigs。

這適用於乾淨的構建,但我不太喜歡遞歸調用。根據我如何調整上述幾行字,我似乎結束了任一個:

  • 不必要的遞歸使得進入linux的樹木,即使沒有什麼變化(這需要7秒鐘,什麼也不做)如果
  • 我編輯linux源碼,內核的重新生成,除非我明確觸摸.config或其他東西。

理想情況下,我希望我的頂層Makefile知道每個Linux內核的內部依賴關係圖,並在所有情況下「做正確的事情」。 (即遞歸製作認爲有害的論點)。

儘管我期望頂級Linux Makefile不會樂意被其他人包括在內,特別是多次使用不同的config和src樹! (我對baz/makefile.inc欄/ makefile.inc有控制權,因此當它們被頂層包含在內時,它們可以被編寫爲播放效果很好)

或者我運氣不好,只需要記住觸摸.configs觸發一個體面的進入每個Linux構建目錄?

謝謝, 戴夫

編輯: 7秒無用的得體的進入一個Linux樹是這個樣子我mahchine:

$ time make 
make -C /home/davidm/md/tests/linux O=/home/davidm/md/tests/linux_a vmlinux 
make[1]: Entering directory `/home/davidm/linux-2.6.38' 
    Using /home/davidm/linux-2.6.38 as source for kernel 
    GEN  /home/davidm/md/tests/linux_a/Makefile 
    CHK  include/linux/version.h 
    CHK  include/generated/utsrelease.h 
make[3]: `include/generated/mach-types.h' is up to date. 
    CALL /home/davidm/md/linux-2.6.38/scripts/checksyscalls.sh 
    CHK  include/generated/compile.h 
make[1]: Leaving directory `/home/davidm/md/linux-2.6.38' 

real 0m6.577s 
user 0m2.930s 
sys 0m1.360s 
+0

你能告訴我們'$(A_LINUX_SRC)/ Makefile'嗎?我想其他兩個是相似的。 (有一個關於Make的調用需要七秒鐘什麼也不做......) – Beta

+0

它是標準的linux makefile,來自上游tarball。我已經更新了原始問題,以顯示那些6-7秒鐘在做什麼。 –

+0

對不起,我應該多給幾秒鐘的思考。 – Beta

回答

2

爲了這個正常工作,你真的必須在每個構建中遞歸到內核源代碼目錄中。 7秒對於檢查大規模內核樹中的任何文件是否已經發生變化沒有什麼不好...

在構建中包含內核makefile實際上不會有幫助,因爲內核構建本身使用遞歸make。

也許是這樣的:

a/.config 
     mkdir -p a 
     $(MAKE) -C $(A_LINUX_SRC) O=$(PWD)/a $(A_LINUX_DEFCONFIG) 

.PHONY: kernel-a-build 
kernel-a-build: a/.config 
     $(MAKE) -C $(A_LINUX_SRC) O=$(PWD)/a vmlinux 

bigfile: kernel-a-build 

由於kernel-a-build就是一個「假」的目標(不對應一個物理文件),它會在每一個建設運行,讓內核生成文件注意源文件的更改。

+0

謝謝,這是我第一個要點所暗指的。我想我希望有人有一個偷偷摸摸的把戲。當我可能擁有多達7個內核時,這7秒加起來,唯一的變化是在'baz'中立即重新編譯。它看起來像我只需要吃它。 但是,然後'sometool'需要40秒來處理反正,所以不是這樣,這是一個超快速的迭代工作流程。 我會接受這個,因爲它的確認是我對SOL的懷疑,而且。使用比我以前強迫詭計更好。謝謝! –