我有一個插件項目，我已經開發了幾年，插件可以與[主應用程序版本，第三方庫版本，32位與64位]。是否有一種（乾淨的）方式來使用autotools來創建一個生成插件的所有版本的生成文件。自動工具可以創建多平臺makefiles
據我所知，通過瀏覽autotools文檔可以看出，最接近我想要的是有N個獨立的項目副本，每個副本都有自己的makefile。 （a）我需要不斷在所有不同的副本中傳播代碼更改，並且（b）複製項目時存在大量浪費的空間。有沒有更好的辦法？
編輯：
我一直在我自己的滾動解決方案一段時間，我都看上生成文件和一些Perl腳本追捕各種第三方庫版本等。因此，我對其他非自動工具解決方案開放。對於其他構建工具，我希望它們對於最終用戶來說非常容易安裝。這些工具還需要足夠聰明才能捕捉各種第三方庫和頭文件，而不會遇到大量麻煩。我主要是在尋找一個linux解決方案，但是一個也適用於Windows和/或Mac的應用程序將是一個獎金。
我們試過了，它不起作用！所以我們現在使用SCons。
編輯： 一些小例子，爲什麼我愛SCons的：
env.ParseConfig('pkg-config --cflags --libs glib-2.0')
有了這行代碼添加GLib庫的編譯環境（ env）。不要忘記User Guide，這對學習SCons非常有用（你真的不需要知道Python！）。對於最終用戶，您可以嘗試使用PyInstaller或其他類似的東西。
與make相比，你使用Python，所以一個完整的編程語言！考慮到這一點，你可以做一切（或多或少）。
我會看看scons。我以前沒聽說過。 – 2008-11-27 20:16:03
如果你的問題是：
我可以使用一些計算機A上的自動工具來創建一個單一的普遍生成文件，將所有其他計算機上工作？
然後答案是「否」。 autotools甚至沒有試圖這樣做的幌子。它們被設計爲包含便攜式代碼，用於確定如何在目標機器上創建可行的生成文件。
如果你的問題是：
我可以使用自動工具來配置需要在不同的機器上運行，使用不同版本的該我的插件的工作原理與主要的軟件，加上各種第三方庫軟件，更不用說32位和64位問題了？
那麼答案是「是」。 autotools被設計爲能夠做到這一點。此外，他們在Unix，Linux，MacOS X，BSD上工作。
我有一個程序SQLCMD（它預編譯了同名十年以上的微軟程序），它可以與IBM Informix數據庫一起工作。它檢測客戶端軟件（稱爲IBM Informix ESQL/C，IBM Informix ClientSDK或CSDK的一部分）的版本是否安裝，以及它是32位還是64位。它還檢測軟件的安裝版本，並根據支持產品中的功能調整其功能。它支持在17年左右發佈的版本。它是自動配置的 - 我必須爲Informix功能編寫一些autoconf宏，以及其他一些gizmos（高分辨率時序，/ dev/stdin等）。但它是可行的。另一方面，我不嘗試併發佈一個適合所有客戶機器和環境的makefile;有太多的可能性，這是明智的。但autotools爲我（和我的用戶）照顧細節。他們所做的只是：
./configure
這比編制makefile文件更容易。 （呵呵，前10年，這個程序是手工配置的，儘管我設置了很好的默認設置，但人們很難做到這一點，這就是爲什麼我轉向自動配置：它使得它更容易人安裝）
福茲先生評論道：
我想要的東西之間。在我的情況下，客戶將在同一臺機器上使用同一基本應用程序的多個版本和位數。我不擔心交叉編譯，例如在Linux上構建Windows二進制文件。
你需要單獨構建32位和64位版本的插件嗎？ （我假設是 - 但是你可以讓我感到驚訝。）所以，你需要提供一個機制，爲用戶說
./configure --use-tppkg=/opt/tp/pkg32-1.0.3
（其中tppkg是您的第三方封裝代碼，且位置）但是，請記住可用性：用戶提供的提供的選項越少越好;相反，不要硬編碼應該是可選的東西，比如安裝位置。通過一切手段尋找默認位置 - 這很好。並默認你找到的東西的狡猾。也許如果你找到了32位和64位版本，那麼你應該建立兩者 - 但這需要仔細構建。您始終可以回顯「檢查TP包裝...」並指出您找到的內容以及您在哪裏找到它。然後安裝程序可以更改選項。確保你在'./configure --help'中記錄什麼是選項;這是標準的autotools練習。
不要做任何互動的事情;應該運行配置腳本，報告它的功能。Perl Configure腳本（注意大寫字母 - 它是一個完全獨立的自動配置系統）是爲數不多的密集交互式配置系統之一（這可能主要是因爲它的傳統;如果重新開始，它很可能是非-互動）。這樣的系統比非交互系統更麻煩。
交叉編譯很困難。我從來不需要這麼做，謝天謝地。
福茲先生還表示：
感謝額外的意見。我在尋找類似：
./configure --use-tppkg=/opt/tp/pkg32-1.0.3 --use-tppkg=/opt/tp/pkg64-1.1.2
它會在一個生成文件同時創建32位和64位的目標爲當前平臺。
嗯，我相信它可以做到;我不太確定，通過兩次單獨的配置運行與完全重建之間的比較，它是值得的。您可能想要使用：
./configure --use-tppkg32=/opt/tp/pkg32-1.0.3 --use-tppkg64=/opt/tp/pkg64-1.1.2
這表示兩個單獨的目錄。您必須決定如何構建，但假設您有兩個子目錄，例如'obj-32'和'obj-64'，用於存儲單獨的目標文件集。您也想安排你的makefile線沿線的：
FLAGS_32 = ...32-bit compiler options...
FLAGS_64 = ...64-bit compiler options...
TPPKG32DIR = @[email protected]
TPPKG64DIR = @[email protected]
OBJ32DIR = obj-32
OBJ64DIR = obj-64
BUILD_32 = @[email protected]
BUILD_64 = @[email protected]
TPPKGDIR =
OBJDIR =
FLAGS =
all: ${BUILD_32} ${BUILD_64}
build_32:
${MAKE} TPPKGDIR=${TPPKG32DIR} OBJDIR=${OBJ32DIR} FLAGS=${FLAGS_32} build
build_64:
${MAKE} TPPKGDIR=${TPPKG64DIR} OBJDIR=${OBJ64DIR} FLAGS=${FLAGS_64} build
build: ${OBJDIR}/plugin.so
這假定該插件將是一個共享對象。這裏的想法是autotool會檢測第三方包的32位或64位安裝，然後進行替換。如果需要32位軟件包，BUILD_32宏將被設置爲build_32，否則爲空; BUILD_64宏將被類似地處理。
當用戶運行'make all'時，它將首先構建build_32目標，然後構建build_64目標。要構建build_32目標，它將重新運行make併爲32位版本配置標誌。同樣，要構建build_64目標，它將重新運行make並配置64位版本的標誌。所有受32位和64位構建影響的標誌都設置在make的遞歸調用中，並且認真編寫構建對象和庫的規則非常重要 - 例如，將源編譯爲對象的規則必須要小心在正確的對象目錄中的目標文件的地方 - 使用GCC，例如，您將指定（在.c.o規則）：
${CC} ${CFLAGS} -o ${OBJDIR}/$*.o -c $*.c
宏CFLAGS將包括$ {FLAGS}值與交易位（例如，FLAGS_32 = -m32和FLAGS_64 = -m64 , and so when building the 32-bit version, FLAGS = -m32 would be included in the CFLAGS`宏。
殘留自動工具中的問題是如何確定32位和64位標誌。如果最壞的情況發生，你必須自己編寫宏。不過，我希望（沒有經過研究）可以使用autotools套件中的標準設施來完成。
除非你自己創建一個仔細（甚至是無情）的對稱makefile，否則它將無法可靠地工作。
我想要介於兩者之間的東西。在我的情況下，客戶將在同一臺機器上使用同一基本應用程序的多個版本和位數。我不擔心交叉編譯，例如在Linux上構建Windows二進制文件。 – 2008-11-27 18:09:15
你有沒有考慮過在多個構建目錄中使用單個項目？ 如果你的automake的項目是在一個適當的方式來實現（即：不喜歡GCC）
以下是可能的：
mkdir build1 build2 build3
cd build1
../configure $(YOUR_OPTIONS)
cd build2
../configure $(YOUR_OPTIONS2)
[...]
你能夠通過不同的配置參數，如包含目錄和編譯器（交叉編譯器IE）。
然後你可以甚至在一個單一的發出呼叫運行
make -C build1 -C build2 -C build3
由於運行此。我正在讀兩篇文章，看看哪些更有可能處理構建過程的一些複雜性，例如調用特定應用程序特定的構建包裝器，而不是直接調用gcc。 – 2008-11-27 20:17:25