不少現(xiàn)存的第三方開源程序是用autotools來組織的，將其加入到CMake的代碼里的時候，有個麻煩的問題是，makefile的更新會產(chǎn)生不一致，尤其是./configure腳本的執(zhí)行速度實在不敢恭維，當(dāng)然希望往Windows上移植的話，是另外一個大問題了。
對于源代碼比較少的程序，基本可以通過比照config.h的內(nèi)容，類比造出一個CMake風(fēng)格的配置文件，然后利用下述命令：
configure_file(config.h.in config.h)
這個方法可行的根源在于，CMake提供了類似的機制來進(jìn)行跨平臺的檢測，具體來說是如下幾個Module：
CheckFunctionExists
CheckIncludeFile
CheckIncludeFileCXX
CheckIncludeFiles
CheckLibraryExists
CheckStructHasMember
CheckSymbolExists
CheckTypeSize
CheckVariableExists< /div> 對于大部分簡單的config.h，
CheckIncludeFile/CheckIncludeFiles/CheckLibraryExists /CheckFunctionExists就足夠了。
需要的工作是，手工寫一個config.h.in，另外加一個 Detect.cmake，在config.h.in里邊，將對應(yīng)的聲明變化cmakedefine,在Detect.cmake里邊，加上查找對應(yīng) macro的方法.
/*Define to 1 if you have <netinet/in.h>*/
#define HAVE_NET_INET_IN_H 1
對應(yīng)的聲明分別為： //config.h.in
#cmakedefine HAVE_NET_INET_IN_H
//detect.cmake
INCLUDE(CheckIncludeFile)
CHECK_INCLUDE_FILE(netinet/in.h HAVE_NET_INET_IN_H)
其內(nèi)部的工作機制為：根據(jù)宏參數(shù)構(gòu)造一個基本的C文件，然后用CC編譯看是否有錯誤，如果沒有，則定義上述符號（HAVE_XXX_H），否則，undefine.對于某些系統(tǒng)頭文件而言，可能頭文件自身是不完備的（依賴于其他的頭文件），此時需要按照依賴順序?qū)懗鰧?yīng)的頭文件序列： /*Define to 1 if you have xxx/yyy.h */
#define HAVE_XXX_YYY_H
//detect.cmake
INCLUDE(CheckIncludeFiles)
CHECK_INCLUDE_FILES("dir1/top1.h;dir2/top2.h;xxx/yyy.h" HAVE_XXX_YYY_H)
- 庫檢測已經(jīng)查找?guī)熘械哪骋粋€函數(shù)
對于檢查庫存在與否的情況，則稍微有些復(fù)雜，config.h通常會如下（autoconf的情況）： /*Define to 1 if you have the library `xxx'*/
#define HAVE_LIBXXX對應(yīng)的定義部分即config.h.in
沒有太大差異，照樣cmakedefine即可。對于detect.cmake,需要指明lib中的一個函數(shù)： INCLUDE(CheckLibraryExists)
find_libaray(libloc libname)
#Get the library directory
string(REGEX REPLACE ".*/(.*)" "\\1" libloc ${libloc})
CHECK_LIBRARY_EXISTS(XXX fun_in_lib ${libloc} HAVE_LIBXXX)
上述方法可以很檢測某個庫中是否包含某個需要的函數(shù)，只有找到的情況下，才定義對應(yīng)的宏。如果只需要知道庫是否存在，只需要根據(jù)find_library的結(jié)果即可： find_libaray(libloc xxx)
if (libloc)
set(HAVE_LIBXXX 1)
endif()
函數(shù)的處理方法則相對簡單，只需要如下的cmake代碼即可：
INCLUDE(CheckFunctionExists)
CHECK_FUNCTION_EXISTS(testfunc HAVE_TEST_FUNC)
上述代碼可能在某些情況下不能正常工作，或者你不知道需要怎樣去填入里邊的信息（比如多頭文件依賴順序的問題），那么可以自己手工模擬對應(yīng)CMake模塊的工作方法，自己造一個C文件來編譯，看看缺少哪些頭文件或者鏈接庫。
如果手邊有現(xiàn)成的autotools生成的config.h，并且這個文件比較大，手工一一改動有些太繁瑣。注意到autoconf 生成的config.h文件有某些特征，用腳本來做某些自動化轉(zhuǎn)換是可能的，一個可行的思路是，通過正則表達(dá)式匹配來檢測注釋，從而可以得出接下來的宏聲明是頭文件還是庫、函數(shù)等，由于宏命名的規(guī)律性，可以很容易的推導(dǎo)出對應(yīng)的頭文件名或者函數(shù)名。
在我自己實驗的一個例子中，用100行的python腳本可以轉(zhuǎn)換得到200個可以正常工作的cmake代碼和 config.h.in。