2013-08-16 13 views
2

我正在處理一個包含許多源文件的大型C項目。下面是從生成文件的一個行:

!$(TOOLSDIRECTORY)unifdef $(UNIFDEF_ARGUMENTS) $** > $(TARGET)\$** 

該行引用的Unifdef工具是開源的,可以在這裏找到: http://dotat.at/prog/unifdef/

在這種情況下,最後一個參數Unifdef是該組的要處理的文件。我的理解是,這段代碼使用符號「$ **」來表示「此文件夾中的每個文件」,然後將所有輸出傳送到TARGET目錄。

我的困惑是,我不明白Unifdef如何在一個命令中接收多個文件。當makefile看到「$ **」時,是否將所有文件打包到一個文件流中?我理解Unifdef如何處理它接收到的輸入,但是如何將多個文件變成Unifdef接收的單個參數?

其他說明:此生成的文件被在2010年MSVS

+0

沒有看到那個目標,我不能說我明白它想做什麼,但它對我來說肯定不是很理智。 '$ *'是[自動變量](http://www.gnu.org/software/make/manual/make.html#Automatic-Variables),它包含匹配的隱式規則的詞幹。 '$ **'應該擴展爲' *',這在重定向的左側可能是合理的,作爲通配符在大量文件上運行unifdef,但重定向的右側看起來很奇怪我。 –

回答

1

Windows CMD提示將$ **擴展爲對Unifdef的多個單獨調用,每個調用都以目錄中的一個文件作爲參數,並將輸出管道輸出到目標目錄中同名文件。因此,每次對Unifdef的調用都只接收一個文件名作爲其輸入。

0

在Windows上運行我懷疑這實際上並沒有做你想做的。

$**不是單個構建體;它是special Makefile variable $*,緊接着是shell-glob通配符*。該生產線將被重新寫入兩次:通過製作第一,要像

!../path/to/tools/unifdef --opt1 --opt2 foo* > ../path/to/target/foo\* 

,然後通過/bin/sh,喜歡的東西

!../path/to/tools/unifdef --opt1 --opt2 foo.c foo1.c foo2.c fooquux.c \ 
    > ../path/to/target/foo* 

,然後才執行。

你沒有引用任何的上下文,所以我不能再比這個更具體。這也是爲什麼我覺得這不可能是正確的,但:

  1. 除非也許你設置.RECIPEPREFIX,這是一個功能,我從來沒有聽說過的現在,!在命令的開頭不作任何意義,並應導致命令失敗,因爲沒有可執行文字字面上!../path/to/tools/unifdef

  2. 上的$**第二次出現的反斜線不逃脫$*(你會做的是通過寫$$*);它被保留下來,並且逃離了shell-glob星形,所以輸出被寫入一個字面上名爲../path/to/target/foo*的文件,這個文件非常奇怪,我不認爲它可能是預期的。

  3. 如果目標目錄的glob沒有被轉義,將有兩個問題:

    • 水珠膨脹獨立地發生在源和目標的目錄,等等將(至少潛在地)匹配不相關的文件集。

    • 輸出重定向(>)僅適用於下一個東西在命令行;目標目錄中glob匹配的所有其他內容將被提供爲輸入unifdef

基於對你想要做什麼野生稱職的猜測,我想你也許想要更多的東西是這樣的:

# Resist the temptation to use wildcards. It will be less grief in the long run 
# to list each file explicitly. 
GENERIC_SOURCES := foo.c foo1.c foo2.c fooquux.c barblurf.c barbaz.c 

UNIFDEFED_SOURCES := $(patsubst %.c,$(TARGET)/%-u.c,$(GENERIC_SOURCES)) 

# The indented lines below must be indented using exactly one hard tab character. 
$(UNIFDEFED_SOURCES): %-u.c: %.c 
     $(TOOLSDIRECTORY)unifdef $(UNIFDEF_ARGUMENTS) $< > [email protected] 
     mv -f [email protected] [email protected] 

這並不試圖調用批處理的unifdef;如果每個規則只創建一個輸出文件,則製作一般更快樂。

$(patsubst ...)static pattern rule是特別是GNU make的特徵。我通常提倡可移植性,但在Make的情況下,GNU化身比便攜式功能集強大得多,因此值得隨身攜帶。

+0

我很感謝你的回答,如果可以的話,我會投票的,因爲它似乎適用於最初提出的問題。 – skrrgwasme