我有一個SCons構建系統，用於從C++構建一些庫，以及通過SWIG構建它們的Python包裝。然後將結果用於數據處理，這也是SCons構建的一部分。數據處理是使用構建的SWIG包裝庫的Python腳本。如何推遲SCons源碼掃描器的運行？
我已經建立了依賴關係，以便在所有庫和包裝器都生成後開始數據處理，並且工作得很好。但有一個警告（你猜對了，對吧？:)）。我想添加一個源掃描器，它也使用一些SWIG庫來擴展依賴關係。問題是掃描儀運行得太快。事實上，我發現它運行兩次 - 一次在構建的早期階段，另一次在數據處理開始之前。因此，第一臺並行運行的掃描程序通常在所有必要的庫建立之前發生，因此失敗。
如何使掃描儀本身依賴於庫目標？
或者，我是否可以延遲掃描儀運行 - 或取消第一臺掃描儀運行？
還有其他想法嗎？
一種解決方法我認爲的工作原理是將掃描器變成運行掃描進程而不是掃描程序的生成器，並生成列出所有依賴項的文件。數據處理構建可以簡單地使用掃描器來解析該文件。我希望SCons不要嘗試提前運行它，因爲它會意識到掃描的源文件是某些構建器的目標。
假設它工作，它仍然是一個子解決方案，因爲它使構建設置複雜化，並添加了一個不太小文件的額外文件I/O（依賴項是數千個文件，具有長路徑） 。
這是另一種解決方法，它是另一種解決方法。如果* .i swig接口文件作爲「節點」參數傳遞給它，掃描器是否可以推測將生成的文件列表？通過這種方式，掃描器實際上並不需要存在的文件來生成依賴關係列表。
一般來說，我想知道這個問題的解決方案是否只是寫邏輯來積極推測SWIG庫實際生成之前的依賴關係。我不認爲通過查看「_ *。so」文件本身可以獲得很多信息。
掃描儀「節點」會自動從關聯的構建器中逐一創建源文件，以及發射器生成的任何內容。如果缺少掃描儀輸入指定，則生成失敗。而且您仍然無法在該掃描儀中使用SWIG庫。 –
但是，我的理解是，scons實際上並不需要依賴關係存在。如果以前的構建器將這些文件包含爲其目標之一，則scons會高興地執行構建，因爲它已承諾由掃描器指示的相關依賴關係將由構建器生成，該構建器將在對應於掃描器的構建器之前運行。 –
所以你想要工作的是，你用scons構建一個python模塊（編譯），然後在scons中加載該模塊並使用它？ – bdbaddog
是的，基本上。僅在掃描儀中使用它，而不是在構建配方本身。如果掃描程序只在構建目標之前運行，它將正常工作。 –