相关疑难解决方法(0)

在项目中共享Delphi源文件的最佳方法是什么？

澄清:我们想在多个Delphi项目中使用单个源文件.我们一直在使用我们的SCM工具将相同的文件放入多个文件夹中,但这不是一种超级优雅的体验,我们也在考虑迁移到不支持此功能的工具.

正如我一直在研究这个问题,我考虑过几种不同的方法,但我想知道你在做什么以及如何找到你的方法.

重要场景​​:

• 码时间
  • 添加新的共享依赖项应该需要显式声明,以便管理共享.
  • 添加新的共享依赖项应该仍然相对简单; 它不应该需要复杂的过程.
    • 列出所有项目的"导入"文件(来自外部)的一个文件会很好.
• 编译时
  • 所有项目应始终使用一个当前版本构建(当前源同步状态的当前版本加上本地编辑).
    • (在不同位置维护不同的版本应该使用文件分支,这不是主题,在这里.)
  • 每个项目是否应该能够使用不同的编译器设置(包括标志)来影响共享文件的编译是有争议的.
    • 维护(即长期)源代码总是更容易维护.
    • 如果所述变更的范围可以很容易地限制在一个项目中,则可以更容易地进行维护修复(即短期).
• 调试时间
  • 当进入例程或设置断点时,源的正确版本应自动打开.
  • 编辑显示的源应该会影响下一个构建.
    • 我们不想针对源的临时副本进行调试:我们可能会在混乱中丢失代码.

注意事项:

• 短期:
  • 最简单的方法是什么？
• 长期:
  • 什么方法最简单易用？

在此先感谢您的反馈!

马蒂亚斯

感谢您的反馈,通过答案,评论和投票!

我已经开始将共享文件放入一个"生产者"项目并将编译文件列表导入每个"消费者"项目.这些项目与MSBuild链接在一起.一旦事情变得更加明确,我将编辑这个问题和"图书馆计划"的答案,分享我所学到的知识.

敬请关注!(但不要屏住呼吸;你会在几分钟内窒息!:P)

我正在尝试解决此编译错误,仅在Debug配置中发生,并且仅在下面描述的情况下:

[dcc32 Fatal Error] MyIndyTCPChannel.pas(22): F2051 Unit IdIOHandlerSocket was compiled with a different version of IdGlobal.IdDisposeAndNil

我正在开发一个非常大的Delphi代码库,拥有250万行内部代码和300万行组件代码,其中包括几个大型商业Delphi组件套件(Developer Express,TeeChart等),以及大量代码库开源delphi组件,以及一个相当大的内部开发组件集,编号252个包,其中大约140个是设计时+运行时或设计时,其他是运行时包(也被加载到IDE中)在运行时,由其关联的设计时包中的DLL依赖项).

我们的主库路径已经优化到尽可能小,并且它包含Delphi附带的路径作为标准,再加上我们添加的三个,主要的是单个"OurCompanyLibraryDCU"文件夹,其中包含下面的文件夹我们使用的两个平台和两个配置:

c:\dev\OurCompanyLibraryDCU\Win32\Release
c:\dev\OurCompanyLibraryDCU\Win32\Debug
c:\dev\OurCompanyLibraryDCU\Win64\Release
c:\dev\OurCompanyLibraryDCU\Win32\Debug

上述每个文件夹都包含一个文件夹中的BPL,DCP和DCU文件集,用于该平台/配置组合.

在项目选项中使用了如下的宏,因此我们可以更改平台和配置,并正确解析目录:

$(OURCOMPANYLIBRARYDCU)\$(Platform)\$(Config)

OURCOMPANYLIBRARYDCU是一个环境变量,$(X)是在Delphi IDE的上下文中扩展环境变量的语法.

我正在尝试将最重要和最大的VCL应用程序项目(称为BigApp.dproj)构建,以便项目搜索目录仅包含我们的APPLICATION源文件夹,并且不需要项目搜索路径来包含我们所有的第三方组件LIBRARY源代码.为此,我们需要链接调试DCU或释放DCU.

到目前为止,除了可以使用Debug和Release DCU的情况外,我们一切正常.版本DCU位于库路径中,调试DCU位于IDE设置中的Debug DCU路径中.面对这两个库之间的选择,Delphi的链接器似乎失败,每当存在两组DCU时,这种形式的错误,当我单击Build,并且Build Configuration设置为Release时,我得到F2051错误.F2051错误的普通原因是存在多个不兼容的二进制DCU并且都是可访问的,并且链接器无法使其全部工作.但是,如果你想在库路径中同时使用Debug和Release DCU,我认为这种情况不会发生,因为Linker会为你选择调试或释放DCU.

如果我没有构建调试DCU,则不会发生上述问题.我怀疑我的调试DCU是微妙的"无效"或Delphi中的Debug-DCU选择算法不起作用,但不知道为什么,或如何解决这个问题.

多部分问题:

A.每个平台/配置组合都有一个文件夹,在单个文件夹中包含DCU,BPL和DCP,然后添加到已知导致问题的IDE库路径中？我是否需要三个子文件夹,每个平台+ config + filetype共有12个文件夹,或者我可以通过platform + config将它们保存在一起吗？

B.在包编译情况下,是否可以让IDE库路径包含OurCompanyLibraryDCU文件夹,并将该文件夹配置为DCP输出目录,包输出目录和单元输出目录？我担心的是,通过使输入文件夹和输出文件夹相同,有一种情况是编译器可能无法从.pas源重建单元,只是链接先前编译的DCU.

C.如果我发生了这个问题,我应该如何防止每次构建BigApp时从源代码编译超过250万行的组件LIBRARY代码,而只是通过DCU链接它们,并且仍然有调试并释放dcus正常工作？

D.如果我转到Win32\Debug文件夹并删除IdGlobal.dcu,我可以通过原始错误.这告诉我,我的包编译(用于调试配置)正在生成INVALID IdGlobal.dcu.这甚至可能吗？delphi可以默默输出乱码的DCU吗？

注意:我没有使用,也无法使用Runtime Packages来处理应用程序大小问题.

更新:我应该在这里做的第一件事是验证ZERO额外的DCU文件在我的硬盘驱动器上是任何地方,无论如何.这是标准的F2051错误建议.在我处理完这个问题后,我会更新这个问题.似乎Delphi本身可以将DCU从一个地方复制到另一个地方,或者不在CURRENT搜索路径中的虚假DCU可能已经在某个其他项目的搜索路径中.可能会出现一种坏DCU拷贝的桶式旅.一旦我确定发生了什么样的坏DCU代或副本,我就会更新问题.

更新2:我现在保证在构建之前不存在IdGlobal.dcu的额外副本,并且问题仍然存在.因此,问题随后打开了构建IdGlobal.dcu时使用的编译器选项,版本化了在Debug构建中构建BigApp.dproj时使用的编译器选项.

更新3:虽然我的所有程序包编译似乎都没有错误地完成,但是在启动DCC32.exe或MSBUILD.exe来构建程序包期间,它们似乎没有使用正确的库搜索路径.这个库路径不一致问题似乎是核心问题,感谢Rufo爵士指出这一点.

这个问题类似于这一个,但不是重复的,因为我询问有关这个问题没有讨论的问题.

我在Delphi 7中有一个客户端 - 服务器项目,具有以下目录结构:

\MyApp
  \MyClientApp
  \MyServerApp
  \lib

有两个实际的Delphi项目(.dpr),MyClientApp和MyServerApp文件夹各一个.

lib文件夹具有.pas单元,它们具有客户端和服务器应用程序的公共代码.我想知道的是我是否应该在客户端和服务器项目中包含那些.pas文件？或者我应该在包含这些单位的lib文件夹中创建一个包？或者我应该将.pas文件保留在lib文件夹中,而不是将它们添加到任何应用程序/包中？

每种方法的优缺点是什么？哪种方式"最好"？将lib文件夹中的这些单元包含在多个项目中是否有任何问题？

现在,lib文件夹中的单元不是任何app/package的一部分.这样做的一个缺点是,当我在Delphi中打开我的客户端应用程序时,我想在项目中的所有文件中搜索某些东西,它也不会搜索lib文件夹中的单元.我通过打开这些单元并在所有打开的文件中进行查找,或使用grep搜索(但我更喜欢更好的解决方案)来解决这个问题.

我也非常喜欢一个解决方案,我不必去打开一些单独的包并在我对lib文件夹中的那些文件进行更改时重新编译它(这是我应该使用项目组吗？).

查看我们的代码库,一些代码明确地包含在项目中,并从搜索路径中提取.有没有人对哪种最佳做法有什么意见？为什么？

更新:

我以为我会澄清我的问题.我们所有的路径都是亲戚,因此我们可以拥有多个分支,这些分支都引用其分支中的代码.所以我不是在询问相对路径,而是单位是否应该在.dpr中或者是否使用搜索路径获取,这就是为什么之前提出的问题并不能完全满足我的需求.谢谢大家