我有一個基於SCons的分層構建系統。我有一個根SConstruct,它調用構建共享庫的SConscript,然後構建一個不同的SConscript,構建一個依賴共享庫的可執行文件。SCons庫和子庫
因此,這裏是我的問題:我在Linux上共享庫的理解是,當你想要做的最後ld
鏈接的可執行文件將使用共享庫,共享庫必須包含在可執行文件的ld
命令行作爲參考源(除非它位於標準位置,在這種情況下-l
選項可以工作)。
所以這裏的東西就像我SCons的文件看起來是這樣的:
=== ROOTDIR/SConstruct
env=DefaultEnvironment()
shared_lib = SConscript('foolib/SConscript')
env.Append(LIBS=[shared_lib])
executable = SConscript('barexec/SConscript')
=== ROOTDIR/foolib/SConscript
env=DefaultEnvironment()
env.Append(CPPPATH=Glob('inc'))
penv = env.Clone()
penv.Append(CPPPATH=Glob('internal/inc'))
lib = penv.SharedLibrary('foo', source=['foo.c', 'morefoo.c']
Return("lib")
=== rootdir/barexec/SConscript
env=DefaultEnvironment()
exe = env.Program('bar', source=['main.c', 'bar.c', 'rod.c'])
Return("exe")
所以這裏的結是這一行:
env.Append(LIBS=[shared_lib])
這將產生庫添加到了需要它們的任何其他庫的命令行的好方法,但因爲SCons的是做一個兩通運行通過SConscripts(第一生成它的依賴關係樹,然後做的工作),rootdir/foolib/libfoo.so
風了所有產品的命令行上,即使libfoo.so
本身:
gcc -g -Wall -Werror -o libfoo.so foo.o morefoo.o libfoo.so
那麼這是怎麼最好地使用SCons做了什麼?現在我已經使出了這個技巧:
=== ROOTDIR/SConstruct
env=DefaultEnvironment()
shared_lib = SConscript('foolib/SConscript')
env['shared_lib'] = shared_lib
executable = SConscript('barexec/SConscript')
...
=== ROOTDIR/barexec/SConscript
env=DefaultEnvironment()
exe = env.Program('bar', source=['main.c', 'bar.c', 'rod.c'] + env['shared_lib'])
Return("exe")
是還有更多的SCons-y方式來做到這一點?
這聽起來像個好主意,但是這不會顛覆SCons的依賴檢查嗎?如果我將LIBS = foo添加到條形圖程序環境中,那麼SCons不一定知道gcc獲取libfoo.so的位置(可能是我的項目,可能是/ usr/lib或SCons知道的任何東西),並贏得' t檢測libfoo.so和barexec之間的依賴關係。我不得不通過env.Depends()來破解foo和bar之間的依賴關係嗎? – 2012-07-20 15:02:53
@TedMiddleton,您必須告訴SCons可執行程序需要哪些庫(通過LIBS構建環境)以及它們在哪裏(通過LIBPATH構建環境),然後在此基礎上創建依賴關係樹。 SCons確實會知道它們,因爲它具有這些變量,隨後它會傳遞給gcc或任何編譯器。你不需要用env.Depends()函數破解任何依賴關係。試試吧,你會看到:) – Brady 2012-07-22 09:21:35