2016-05-30 114 views
0

我們必須在代碼中幾個圖書館舉辦了一個應用程序,其中一些依賴於其他的庫,所以我們有像循環鏈接庫

App 
| 
+--------+--------+ 
|  |  | 
v  v  v 
lib1  lib2  lib3 
|  | 
v  v 
lib3  lib3 

的依賴關係樹最近有人在添加了一個新的方法lib3,它依賴於lib2中定義的類,並且由於這是生成循環包含,所以我們對lib3中頭文件中所需的類進行了前向聲明。

現在,每個庫都被編譯爲一個靜態庫,然後鏈接到其各自的鏈接列表中,因此lib2位於lib2的鏈接列表中,並且lib3也位於lib2的喜歡列表中。

到目前爲止,這工作完美,但我想知道有這種編譯和鏈接依賴關係的缺點。我認爲可能會發生這樣的情況:lib2中的更改不會被lib3注意,除非它被重新編譯,但是我檢查並且lib2中任何頭文件中的任何更改都會觸發lib3的重新編譯(這裏有點運氣)。

是否還有其他重要的缺點我應該知道?

+0

*「... lib2中任何頭文件的任何更改都會觸發lib3的重新編譯。」*爲什麼?這是你在構建系統中強加的東西,還是由於#include語句的模式而自然產生的?如果是後者,你確定所有那些'#include'語句是否真的有必要? – Beta

+0

我在這種情況下使用的一種方法是在一個庫中定義一個具有純虛函數的基類。在其他庫中從它派生。然後你減少依賴。也許還有其他方法。我認爲你應該避免循環依賴。 – user2672165

+0

隨着循環依賴性,您必須始終與所有庫鏈接。然後你可以創建一個大的靜態庫文件。 – user2672165

回答

2

有沒有其他重要的缺點我應該知道?

那麼,order of libraries指定的鏈接實際上很重要。

要擺脫鏈接器用來解決這些依賴關係的順序,通常會提供一個選項來對它們進行分組,例如這些只使用單個文件池。

對於GCC編譯器,這些選項是-Wl,--start-group,-Wl,--end-group