組織的搜索路徑

我們通過「工具|選項|環境變量」創建變量這樣的：組織的搜索路徑

$(Sources) = D:\Sources\Delphi 
$(OurLib) = $(Sources)\OurLib\Src 
$(OurApp1) = $(Sources)\Applications\App1\3.x 
$(ThirdParty) = $(Sources)\ThirdPartyComponents

我們在項目搜索路徑中使用這些變量這樣的：

($OurApp1)\Src\Core;($OurApp1)\Src\GUI;($OurApp1)\Src\Plugins;$(ThirdParty)\JVCL

但這自德爾福2009年以來已經破裂（同時固定），因爲這些變量不再被完全評估（見QC#73276）。所以編譯器找不到目錄中的文件。解決方法：僅使用環境變量中的完整目錄。

我們使用這種方法，因爲在所有開發人員機器和構建服務器上都可以找到文件，我們只需將$（Sources）指向正確的位置即可。

我們沒有任何東西在我們的全局庫路徑中（Delphi默認值除外），因爲這不在版本控制中，並且不會反映在其他開發人員或構建機器上。

一個問題是：如果$（OurLib）中的一個單位決定在另一個新路徑中包含另一個新單元，則所有項目都會因爲沒有找到此新單元而中斷。然後我們必須通過所有項目並添加搜索路徑。（順便說一句：我真的很討厭的搜索路徑編輯器......不會是一個簡單的備註字段更好的編輯比這個替換/添加/刪除邏輯？）

我們做的不是加入許多單位的另一件事情我們項目。尤其是來自$（OurLib）的所有內容，但我們經常擁有像插件這樣的單元，只有通過包含它們才能添加功能。對於我們產品的不同版本，我們希望包含不同的單位。由於Delphi總是在.dpr的uses子句中混淆$ IFDEFs，因此我們通過包含名爲「IncludePlugins」的單元來幫助我們，這些單元包含依賴於IFDEF的單元。但是不包括項目中的單位導致痛苦。單位不會出現在項目中，他們沒有按Ctrl + 12（顯示單元）發現，他們不是在代碼完成顯示等

大家有更好的方法來解決這些問題？

來源

2009-04-23 Steffen Binas

我們只使用相對路徑，任何圖書館總是庫子目錄之下，而項目的源代碼駐留在src子目錄。因此，我們的搜索路徑總是如下所示：

.. \ libs \ library1; .. \ libs \ library2 \ common;

等

所有庫添加爲SVN：外部的每一個項目，所以檢查出的項目會自動檢查出庫，以及與搜索路徑總是指向正確版本的庫爲該項目。

並不完美，但它工作的大部分時間。

我不得不承認有關的搜索路徑編輯器，它是更糟糕的相對路徑，因爲你不能使用「...」按鈕，否則Delphi將插入一個絕對路徑。

來源

2009-04-23 09:45:21 dummzeuch

我們使用標準的驅動器映射。

我們目前的項目總是在W上：不管它是網絡驅動器還是替代品。

This works great。

當您需要處理不同的項目時，請交換W：然後您可以繼續。

來源

2009-04-23 09:00:43

事實上，我們就此別過。我們的構建機器將$（Sources）映射到S：並將得到的二進制文件放在T：創建設置的地方。我們的工具鏈的所有應用程序都不支持更改根目錄。 – 2009-04-23 09:08:12

您可以複製出來的搜索路徑編輯，修改，然後將其複製回來。

來源

2009-04-23 13:33:57

您的搜索路徑太大了。它應該包含只有你想要Delphi重新編譯你的項目的東西。你真的不想每天重新編譯Jedi VCL，是嗎？

我創建一個單獨的目錄，所有編制單位去。說，C：\ dcu。將其指定爲包中的「單元輸出目錄」全部爲包。我的「搜索路徑」，那麼，是總是只是這樣的：

$(Delphi)\Lib;C:\dcu

編譯器發現它所需要的一切，和它從來沒有發現任何的源代碼。它所見到的唯一源代碼是直接屬於我正在編譯的任何項目的文件。項目自己的源代碼目錄不需要在搜索路徑上，因爲所有這些文件都是項目的直接成員。編譯器確切地知道它們在哪裏。

對我來說，所有項目的源文件走在一個單一的目錄中。如果你想爲不同的部分單獨的目錄，如核心和GUI，然後我把這些分開包裝，所以我可以對他們的工作，並分別編譯它們。即使最終的程序不使用生成的BPL，程序包仍然是分割項目和定義依賴關係的好方法。

在編制單位，一個項目不會自動編譯單位的所有其他項目，你不得不改變活動項目。這需要你花一點時間，但它也提醒你，你也在「換帽子」。

雖然您只生產一個產品，但這並不意味着您在Delphi中應該只有一個項目。您的產品中每個可執行模塊（EXE，DLL，BPL）至少應有一個項目。使用項目組可以在單個IDE會話中管理多個項目。任何單位都不應該是多個項目的成員。

我不明白您對插件和項目的不同版本的一部分。當你說「插件」時，我假設你正在討論單獨的可執行模塊，如DLL或包，客戶可以選擇包含或不包含。難道你不能將你的不同版本的功能變成插件模塊，而這些插件模塊不包含在較小的版本中？那麼你不必擔心條件編譯你的項目;只需要幾個不同的安裝程序打包工具來抓取不同的插件集。

來源

2009-04-23 15:08:49

一個DCU目錄：我記得我們已經考慮過這個，但我認爲有重複單元名稱的問題。但我會重新考慮這一點。插件：有些東西很難通過「真實」插件（DLLs/Packages）進行區分，例如，該應用程序的試用版。由於我們不使用軟件包，因此包括例如一個TFrame後代通過一個DLL，因爲我們將不得不接口這個。 – 2009-04-23 16:19:53

我一直覺得奇怪，這從來沒有得到充分解決。我最近向David I建議，Delphi應該允許用戶設置某種首選的開發結構，並且可以讓第三方庫發佈者意識到這一點，以便他們能夠自動調整安裝程序，以便在首選開發框架中正確安裝。如果首選開發結構存儲在XML文件或類似文件中，那麼它可以在開發團隊中從一臺計算機複製到另一臺計算機。

作爲一種替代方案，它可以創建一個有趣的項目來創建一個Delphi應用程序，該應用程序允許用戶以高級方式「重構」其庫安裝。您可以指定系統上的哪些文件夾包含源代碼或編譯組件或任何您想要保留源文件或編譯單元的位置，在更新Delphi環境時打開Go並重新安排系統，以便在啓動Delphi時找到它應該的一切。

來源

2009-04-23 16:28:02 jrodenhi

我剛剛發現了一種在delphi中使用XE6構建項目特定環境變量的方法，它不像C中那樣充分發揮了#define的作用，但至少我現在可以在多個項目並創建一些共享選項集。

我所做的是以與原始海報相同的方式設置環境變量，然後在dproj或optionset中覆蓋它們。

的BuildPaths.optset添加到項目中看起來像

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <PropertyGroup> 
     <SVN_Root>..\..\..</SVN_Root> 
     <SVN_Riemann>$(SVN_Root)\Riemann</SVN_Riemann> 
     <SVN_Library>$(SVN_Root)\Library</SVN_Library> 
     <SVN_ThirdParty>$(SVN_Library)\Third Party</SVN_ThirdParty> 
    </PropertyGroup> 
    <ProjectExtensions> 
     <Borland.Personality>Delphi.Personality.12</Borland.Personality> 
     <Borland.ProjectType>OptionSet</Borland.ProjectType> 
     <BorlandProject> 
      <Delphi.Personality/> 
     </BorlandProject> 
     <ProjectFileVersion>12</ProjectFileVersion> 
    </ProjectExtensions> 
</Project>

來源

2016-04-29 02:04:56

這是一個工作答案或沒有？ – Mostafiz 2016-04-29 02:22:27

組織的搜索路徑

回答

相關問題