我能想到的至少有幾個用例或情景的:如何在DUB中進行配置,將具有主要功能的多個輸入D文件變成多個輸出可執行文件?
- 的「例子」配置中建立多個示例程序。
- 一個包含客戶端程序和主機程序的項目。
- 包含一個主程序和一些相關實用程序(例如:gcc)的項目。
更一般地說,如果項目有多個輸出可執行文件具有相同或相似的一組依賴關係,那麼一次構建它們可能是有意義的。用戶決定運行哪個可執行文件要比找出如何讓DUB創建他們想要的可執行文件更容易(他們可能不是熟悉DUB的D開發人員)。作爲D開發人員也很方便,因爲我可以運行更少的構建命令來獲得我想要的總數。
舉個例子,我可能有類似這樣的工程:
dub.json
.gitignore
source/common/foo.d (Code called by all examples)
source/examples/simple_example.d (Build input with main function)
source/examples/complex_example.d (Build input with main function)
source/examples/clever_example.d (Build input with main function)
bin/simple_example.exe (Output executable)
bin/complex_example.exe (Output executable)
bin/clever_example.exe (Output executable)
另一個項目可能是這樣的:
dub.json
.gitignore
source/common/netcode.d (Code called by all programs)
source/common/logic.d (Code called by all programs)
source/executables/host-daemon.d (Does privileged things for the server)
source/executables/server.d (Unprivileged network endpoint)
source/executables/client.d (Queries the server)
bin/host-daemon (Output executable)
bin/server (Output executable)
bin/client (Output executable)
在任何項目中,我會想建立的所有可執行文件與一次調用DUB。理想情況下,由於輸入和輸出的相關性,這將全部由一個dub.json文件管理。
好像subPackages也許能夠做到這一點,但是從一個dub.json文件管理則是「一般不提倡」:
的子目錄/ COMPONENT1和/ COMPONENT2則含有正常的包,且能夠被稱爲「mylib:component1」和「mylib:component2」來自外部項目。要引用同一存儲庫中的子包,請使用「*」版本說明符。
也可以在根包文件中定義子包,但請注意,它是
generally discouraged
將多個子包的源代碼放入同一個源文件夾。這樣做會導致隱藏的依賴關係到未包含在「依賴項」部分中的子包。這些隱藏的依賴關係可能會導致構建錯誤,這些錯誤會與某些可能難以理解的構建模式或依賴關係樹結合在一起。
DUB可以一次構建多個可執行文件,如上所述,如果是,那麼最推薦的方法是什麼?爲什麼?
感謝您鏈接該論壇的帖子。它看起來像我可能會成爲另一個subPackage濫用者:配置似乎旨在管理輸出類型和可能的可選依賴項(如在配音的json文件中);批量處理它們的多個輸出並不像我預期的那樣微不足道。有趣的是,D論壇發佈的帖子將DUB問題與1155聯繫起來,其中有人迴應:「[...]有多個例子的情況如何?」我希望不是這樣,但也許這是一個沒有考慮到的用例。 – chadjoan
值得注意的是,當我試圖使用這個配置(作爲一個缺口)時,它會失敗,因爲它試圖在編譯一個示例文件時將所有.d文件包含在examples子目錄中(並給出錯誤消息關於具有多個主要功能)。這是儘管我嘗試''excludedSourceFiles「:[」./source/examples/*「]'在json文件中的所有級別以及''mainSourceFile」:「./source/examples/some_example.d」'in每個配置。因此,我甚至不能測試' - 組合的建議:( – chadjoan