在Delphi中建立一个大型软件系统

Question

我们有一个大约16岁的软件包.几乎每个版本的Delphi(除了.NET版本)都经历过.多年来,当涉及到交叉引用并为其他软件包(如第三方库)保持正确设置时,事情变得非常混乱.我想知道在保持像这样有组织的大项目(和项目组)方面是否有一些标准做法.

那么解释当前的设置......

这是一个多应用系统.意思是,涉及12个可执行项目(以及一些DLL和服务项目).我们还将事物保存在SourceSafe中,并且多个开发人员在不同的计算机上处​​理相同的代码.所有这些项目都被更多地转移到中央文件夹中."根"文件夹中包含的主要EXE项目(约20个文件夹,所有含单位和形式沿),它似乎像文件夹和文件的无尽层次.仅此一个项目就涉及50万行代码.

然后,所有其他应用程序不一定与该主要项目正确分开.这些项目中的每一个都有自己的主文件夹根目录.

我的两个主要问题是:

• 如何正确设置DCU文件,使它们不与项目混合？不应将DCU放在SourceSafe(以及任何类似的文件)或其他任何文件中编译的文件中.Visual SourceSafe在未检出文件时使文件为只读,在这种情况下无法写入DCU文件(和EXE文件等).那么如何正确地将任何此类文件分离到远程位置以避免与源代码混合？
• 如何正确设置包和库？我们有以下内容:
  • QuickReports 5.05
  • NativeJpg库V302 -
  • 另一个匿名报告库
  • 我们自己的组件包,需要QuickReports,NativeJpg和其他匿名库

所有这4个库都存储在每台计算机的完全不同的位置,需要一些集中化.设置每个新开发人员计算机的最大痛苦是从主要开发人员的计算机中找到它们并将它们复制到另一台计算机上的相同位置(并确保库路径正确等).

我们还需要在同一台计算机上为不同版本的Delphi保留完全独立的环境.这意味着每台计算机上的项目副本,每台计算机上的软件包和库的副本,SourceSafe中项目和软件包和库的副本等.每台计算机都需要具有相同的设置.我们已经利用环境变量来指导我们的项目在哪里寻找某些项目文件(和库).

另一个新问题:XE2引入了64位功能.我们不打算在64位编译还,但我们肯定会在未来.如何在所有这些项目中正确区分32位和64位？

我真正要求的是参考一个关于如何优化这样的环境并使其组织最佳的良好教程.我不希望任何人花时间在问题中回答这一切.这些项目已超过15年,拥有来自世界各地的200多名开发人员,并且项目之间有很多交叉引用.例如,一个项目可能使用另一个项目的单位,反之亦然.我个人不喜欢这个概念,但我也没有设计它.我被赋予了使这个系统井井有条的任务,并详细记录了如何在新计算机上设置Delphi以便新开发人员处理我们的项目.当我正在查看我们的项目时(因为我不一定是系统的开发人员,但我正在开发中),我看到代码组织方式存在很多困惑.

我假设Embarcadero可能有一些关于建立这样一个环境的指导方针和标准吗？

Answer 1

DCU文件的位置

关于作为编译过程输出的DCU,应在每个项目文件中指定DCU输出目录.在最新版本的Delphi中,默认值为:.\$(Platform)\$(Config).这导致项目目录的子文件夹如下:Win32\DEBUG或Win64\RELEASE.

如果使用选项集设置项目文件,则可以从少量选项文件中控制此设置(以及所有其他设置).

第三方代码的位置

您应该始终使用第三方库作为代码.如果供应商收取更多费用以接收库作为代码,则支付费用.完成后,只需将源代码包含到版本控制系统(VCS)中,并将其视为与处理自己的代码大致相同的方式.我说很大程度上是因为你应该避免修改它.

在VCS中拥有所有代码之后,您可以将整个源代码放在具有单个结帐操作的新计算机上.

组织您的项目

我个人非常厌恶使用编译器搜索路径.我不使用它们并包含.dpr文件中项目所需的每个单元.

如果您确实使用了搜索路径,那么您就无法处理变体项目.例如,假设您有一个客户端发现了您在2年前发布的软件版本中的错误.您希望通过发布升级到该软件的2年版本来解决该错误.要求他们升级到最新版本是不可行的.也许他们还没有支付升级费用.也许全面升级有一些他们现在不想解决的突破性变化.一个完美的例子是所有仍在使用Delphi 7的Delphi开发人员.

现在,在激发了这个场景的动机之后,你将如何为这个2岁的项目创建一个构建环境？如果您使用搜索路径,那么他们将参考今天的库.您将被迫更改搜索路径,或者将旧库复制到当前库的顶部.

通过不使用搜索路径并将所有源包含在VCS中,可以轻松地完成整个过程.

您应该瞄准的是能够检查您的程序的任何历史版本并立即构建它.您应该能够完全相信您正在构建与发布版本时构建的软件相同的软件.这也要求你拥有构建自动化,但我无法想象你对这个规模的项目缺乏这种能力.

Answer 2

我将解决文件夹组织问题.这来自一个拥有50多个exe和dll以及大量第三方库的软件套件,所以我想我知道你来自哪里......

我们使用Perforce作为源控制系统,因此我的默认工作区的根文件夹称为Perforce,但我还设置了几个其他工作区,它们位于Perforce2,Perforce3等.

常规文件夹设置(从工作区根文件夹开始)

General
  Components
    Delphi
      Indy
        Indy9
        Indy10
      MadCollection
        v2.5.8.0
        v2.6.0.0
  Plugins
Releases
  Released
  ... a folder for each release we publish ... (and equal to a branch in Perforce)
Work
  Acceptance
  Sub1
  Sub2

IDE中的我的环境库路径是空的(甚至没有BDE标准路径在那里).这可确保项目的路径声明所需的所有路径,并且项目不依赖于特定计算机的IDE设置.

我们在IDE中设置了一个环境变量(即MRJ),指向"General\Components\Delphi",因此在项目的选项中,我们将组件的路径声明为$(MRJ)\MadCollection\2.6.0.0.

General拥有我们项目使用的IDE插件和组件.我们保留所有用于源代码管理的版本.这样,当我不得不切换回旧版本来追踪问题时,我可以简单地将其拉出并构建它,因为它的库路径仍将指向此特定版本所需的组件版本.

特定工作分支(Acceptance或其中一个子分支)中的文件夹组织遵循以下模式:

General          
  Includes
  MainComponent1
    Project1
    Project2
    Shared
  MainComponent2  
    Project3
    Project4
    Shared
  Shared
Windows          
  SoftwareSuite  
    Scripts
      Tools
  MainComponent1
    Project1
      Dcus
    Project2
      Dcus
  MainComponent2  
  Tools
    Tool1
      Dcus
    Tool2
      Dcus

General文件夹包含所有与平台无关的源/文件,Windows文件夹包含所有Windows特定文件.每个组件可以容纳多个项目,并且将具有用于在这些项目之间共享的源的共享文件夹.直接在General下的共享文件夹包含所有项目共享的源.Windows文件夹以类似的方式设置.

请注意,每个项目都有自己的dcus文件夹.这是在项目选项中配置的.由于路径可以输入.dcus,我们(至少我)将此设置为任何新项目的默认设置.每个项目将其dcus发送到一个唯一的文件夹可确保两件事:

• 只需在版本控制软件中设置过滤器,即可轻松保持dcu不受版本控制.
• 更重要的是,它确保项目的编译/构建永远不会干扰另一个项目的编译/构建.我可以安全地更改设置并构建,因为我知道我不会被另一个项目的前一个版本中的dcu所困扰.

Answer 3

我推荐以下做法:

1. 保持库路径简单,并确保库路径中的所有内容都是delphi附带的文件夹,或者d:\ Components \文件夹中的DCU二进制文件夹(库).

2. 使用MODERN类型的版本控制.我推荐Mercurial而不是其他人.Source Safe是垃圾,停止使用它.

3. 备份环境(导出注册表项等)并以标准化方式将其还原到其他开发人员PC.您可以保留一些.reg和.cmd(批处理)文件来自动设置新系统.您可以将这些脚本放在版本控制系统的组件存储库中.