2012-11-15 55 views
0

假設我正在圖書館工作,foo。在我的庫源文件,我想包括頭以同樣的方式我的圖書館的用戶將:使庫名包含路徑中的一部分?

#include <foo/bar.hpp> 

// code defining bar methods here 

在提升,例如,包括升壓內的其他頭都這樣做的方式,例如<boost/shared_ptr.hpp>,而不是相對的引用"../shared_ptr.hpp"風格。我研究了其他一些庫如何實現這一點,並且看起來他們在其文件佈局中添加了一個冗餘目錄以便完成它,例如,升壓代碼位於「boost_1_4_1/boost」中,而不是「boost_1_4_1 /」。

如果您已經使用現有佈局進行源代碼管理,切換到該方案很煩人。使用GNU進行分層的最佳方式是什麼?我唯一的想法是添加一個目標,所有構建目標都依賴於使用內部符號鏈接的隱藏文件夾到我的源代碼樹中,並將該隱藏文件夾添加到包含路徑。也許有一種不太混淆的方式?

+3

最好的辦法是擁有「冗餘」目錄。你使用什麼源代碼控制會造成這個問題? –

+0

我剛剛給了源代碼控制作爲例子,我想這將是一個痛苦說CVS,至少如果你沒有訪問權限在服務器上重命名目錄。但它也會讓你的所有路徑更長,在你的編輯器中,在你的外殼等。 –

+1

如果你想使用一個符號鏈接,爲什麼要通過使makefile創建一個隱藏的符號鏈接?爲什麼隱藏?在unix系統上,隱藏的目錄符號鏈接不會被命名爲'foo',因爲它必須以句號開頭 - 導致您的解決方法無法工作。只要創建一個符號鏈接(並將其添加到源代碼控制中),如果這是您想要執行的操作以避免實際移動文件。但我認爲只是移動文件會更好;當文件顯然生活在兩個地方時,它經常讓我感到困惑,所以只有在真正有理由的時候纔會這樣做。 –

回答

0

難道你不能在你的Makefile中使用-I的gcc key選項嗎?

GCC:

的gcc -c -I /家庭/約瑟夫的/ dev /富/頭

的Makefile:

INC=-I/home/joseph/dev/foo/headers 

在這種情況下,你將有隻有一個Makefile進行更改的地方。

+0

但是這並不能解決允許他使用'#include「foo/bar.hpp」'來獲取實際上並不存在於名爲'foo'的目錄中的'bar.hpp'的問題。 –