转向使用 Delphi 包 - 最佳实践好吗？
我正在尝试在使用这些包编译我的应用程序之前开始将我自己的库作为包提供，从而模块化我的代码。多年来，我已经“有点”理解了软件包，当我加载组件包并单击“安装”时，我松了一口气。据我了解，安装一个或多个组件的过程是通过创建 BPL，然后在 IDE 中注册。
我开始迷失的是如何使文件可用，以便我可以使用包或预编译的 dcu 进行编译（就像第三方供应商所做的那样），而无需始终将我的项目指向源代码。我可以使用以下设置创建一个包：
我已指定所有输出都将进入'c:\scratch\wow'。构建后，我发现 TEST.BPL、TEST.DCP 和许多 DUC。现在，当我将另一个项目指向此文件夹以使用 DCU 时，我收到丢失 DFM 错误（其中一个单元是表单）。我应该手动将所需的 DFM 复制到此输出文件夹中吗？ DPK 知道此表格，那么为什么我不为我复制 DFM？我认为使用 TEST.BPL，该文件包含所有内容，但我希望在两种模式下工作。当然，我可以通过在项目搜索路径中包含源文件夹来查找 DFM 来解决这个问题，但第三方库似乎已经在其输出文件夹中包含了 DFM。他们是使用安装程序安装的吗？ 谢谢
I am trying to start making my own libraries avaialble as packages prior to compiling my Apps with these packages hence modularising my code. For years I've 'sort of' understood packages, breathing a sigh of relief when I load a component package and click on 'Install' and it does. I understand that the process of installing a component (or components) is via the creation of a BPL which is then registered with the IDE.
Where I begin to get lost is how to make files available so that I can compile with EITHER a package OR pre-compiled dcu's (like the third party vendors do) and without pointing my project at the source code all the time. I can create a package with the following settings:
where I've specified that all my output will go into 'c:\scratch\wow'. After a build I find TEST.BPL, TEST.DCP and lots of DUC's. Now, when I point another project at this folder to use the DCU's, I get a missing DFM error (one of the units is a form). Should I be manually copying needed DFM's into this output folder? The DPK knows about this form, so why do I not get the DFM copied for me? I presume that using TEST.BPL, that file contains everything, but I wish to work in the two modes. Of course I can get around this by including the source folder in my project search path to find the DFM but third party libraries seem to already have the DFM's in their output folder. Did they install them there using the installer?
Thanks
instead
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
正如其他人所说，您可以使用构建后事件将 DFM 文件复制到位。其他人使用一次性外部批处理文件将 DFM 复制到 DCU 文件夹。
就我个人而言，我认为为那些未开发为可重用组件的东西制作包几乎没有什么好处。当您不需要多次或在设计时使用相同的子部分或包时，我还认为将现有应用程序划分为包几乎没有什么好处。
我会放入包中的东西：
Delphi 可视化和非可视化组件。
绝对必须在运行时插入或省略的东西。例如，假设我出售 MetaWare Light 和 MetaWare Pro，并且不使用编译器 IFDEF 来构建不同的二进制文件，出于某种原因，我更愿意干脆不在我的系统中附带 ADVANCEDFEATURE.BPL。
包需要注意的事情：
在将包与泛型组合时，我遇到了很多编译器错误。我在 Delphi 2009、2010、XE 和 XE2 中也遇到过 IDE 崩溃和锁定的情况。 （我相信 XE3 更好）
在转向 BorlandMM.dll 和 BPL 世界中的共享内存管理之前，您应该了解一些。其中有一些微妙之处。
包限制了链接器决定删除什么内容的能力。事实上，它几乎摧毁了它。包包含链接到其中的所有内容，并且不能删除任何可公开访问的内容。
一旦您创建了一个二进制包并将其运送给甚至一个客户，您就很难修改合同（此 BPL 包含特定的签名或应用程序二进制接口），您将来必须小心，不要更改或将它们混合搭配。小心 DLL 地狱，即使是在您自己的客户中，并准备好在您的包上使用版本控制。正如 delphi 包有一个版本后缀一样，我建议您立即在自己的包中使用版本后缀，并在二进制兼容性发生更改时更改它们。
Delphi 处理包之间的构建依赖关系的效果与预期的一样好，这不如单个整体应用程序好。在我拥有的大量使用包的应用程序中，我发现包含一堆相互依赖的包的项目组很难管理和快速构建。事实上，我的经验是，编译和构建都比单个 750Kline 大型项目更慢、更令人沮丧。
我真的想知道您是否不那么喜欢 Delphi 的软件包领域（每当 Delphi 组件实际构建和安装没有问题时您都会松一口气？），如果您真的想完全进入软件包世界。无论如何，你应该尝试一下。但我还不会把农场的赌注押在这上面。先多了解一些。
As others say you could use post-build events to copy your DFM files into place. Other people use a one-time external batch file that copies the DFMs to the DCU folder.
Personally I see very little benefit to making packages for things which are not developed also as reusable components. I also see very little benefit in partitioning an existing application into packages, when you don't reasonably need to use the same subsection or package more than once, or at designtime.
Things I would put into packages:
Delphi visual and non-visual components.
Things which absolutely must be plugged in at runtime, or left out. For example, supposing I sell MetaWare Light and MetaWare Pro, and instead of using compiler IFDEFs to build a differnt binary, I preferred for some reason to simply not ship the ADVANCEDFEATURE.BPL with my systems.
Things to beware of with packages:
I have run into a lot of compiler bugs when combining packages with generics. I have also run into IDE crashes and lockups, in Delphi 2009, 2010, XE and XE2. (I believe XE3 is better)
You should learn a bit about BorlandMM.dll and shared memory management in the BPL world before you move to it. There are some subtleties.
Packages limits the ability of the linker to decide what to remove. In fact, it pretty much destroys it. Packages contain everything that is linked into them, and nothing publically accessible can be removed.
Once you've created a binary package and shipped it to even one customer, you have a pretty difficult to modify contract (this BPL contains a particular signature or application binary interface) you have to be careful in the future to never change them, or mix and match them. Beware of DLL hell, even among your own customers, and be prepared to use versioning on your packages. Just as delphi packages have a version suffix, I recommend you use version suffixes in your own packages right off the bat, and bump them whenever binary compatibility has changed.
Delphi handles build dependencies between packages about as well as could be hoped, which is less well than a single monolithic application. In applications that I have that make heavy use of packages, I find project groups that contain a bunch of packages that depend on each other are very difficult to manage and build quickly. In fact, I have experienced that both compiles and builds are slower and more frustrating than they would be in a singular 750Kline megaproject.
I really wonder if you're not that into the package area of Delphi (you breath a sigh of relief whenever a delphi component actually builds and installs without issue?) if you really want to move into the Packages World totally. By all means, you should experiment. But I wouldn't bet the farm on it yet. Learn some more first.
是的，您应该将 .dfm 复制到包含编译单元 (.dcus) 的目录，如果这是您在搜索路径中想要的唯一目录。 BPL 当然会包含 .dfms，并且您需要一个 .dcp 才能将 BPL 与您的应用程序链接。
事实上，第三方工具必须使用其安装程序将 .dfms 与 .dcus 放在目录中。
Yes, you should copy the .dfm to the directory with the compiled units (.dcus), if that is the only directory you want in your search path. The BPL will of course contain the .dfms, and you need a .dcp to be able to link a BPL with your app.
Third party tools must have put the .dfms together with the .dcus in the directory using their installer, indeed.
您可以使用构建后事件（项目/选项/构建事件），而不是手动复制 *.DFM，例如：
Instead of copying *.DFM manually you can use Post-Build Event (Project/Options/Build Event), ex:
我找到了一种方法来执行此操作，而无需将 .dfm 文件移动到 .dcu 文件的目录，因此您可以有一个仅用于 .dcu 文件的目录，一个仅用于 .dcp 文件，另一个仅用于 .bpl 文件。
您所需要做的就是在您的良好结构上创建另一个目录，就像我一样。该目录称为 RES，其中应放置使用包（组件）编译的应用程序所使用的所有资源文件（.res 文件，而不是 .dcr 文件）。在 Delphi 库路径中，除了 DCU 目录（您应该已经有）之外，还必须包含名为 RES 的目录。
在您的组件上（设计时）对表单执行您想要的所有操作（设计它，放置其他组件等）。在单元的源代码中，将 {$R *.dfm} 替换为 {$R UnitName.dfm}。执行此操作时，保存所有内容并关闭 DPK。现在将.dfm文件（不要复制，移动！）移动到RES文件夹（.dfm文件是Delphi的资源文件。{$R}指令就是证明！），然后再次打开DPK即可了解发生了什么变化。
首先意识到你可能无法从他的单元打开表单（F12），尽管Delphi没有发出关于“DFM丢失”的错误。
现在，对您的软件包进行构建，然后安装它。又意识到了？没有显示错误！发生这种情况是因为您已在 Delphi 库搜索路径（RES 目录）中指定了 .dfm 文件的位置。
完毕！您可以使用您的组件，当您的组件包含在应用程序中时，就会发现 dfm。
你们中的许多人现在可以说，这样我将不再能够在组件设计时可视化地编辑表单。是的，这是事实，但如果您想一想，为什么我要如此频繁地将表单更改为实际上只应使用和稍微编辑的组件？得出你自己的结论；）
I found a way to do this without moving .dfm files to the directory of .dcu files, so you can have a directory for .dcu files only one for .dcp files only and another for .bpl files only.
All you need to do is to create another directory on your good structure, as I do. The directory is called RES and in it should be placed all the resource files (.res files, not .dcr files) that are used by applications compiled using your packages (components). In the Delphi Library Path, you must include in addition to the DCU directory (you should already have) a directory named RES.
On your component (design time) do everything you want with the form (design it, put other components, etc). In the source code of the unit you replace {$R *.dfm} with {$R UnitName.dfm}. In doing so, save all and close the DPK. Now move the .dfm file (do not copy, move!) to the RES folder (the .dfm file is a resource file to the Delphi. The {$R} directive is proof!) and after that open the DPK again to understand what has changed.
First realize that you may not open the form (F12) from his unit, though no error was issued by Delphi about "DFM missing".
Now, do a Build on your package and then install it. Realized again? No errors displayed! This happened because you have indicated the location of .dfm file in the Delphi library search path (RES directory).
Done! You can use your component and dfm will be found when your component is included in an application.
Many of you can now say that this way I will not longer be able to visually edit a form in the component design time. Yes this is true, but if you think about it, why would I want to change so often a form into a component that, in practice, should only be used and slightly edited? Draw your own conclusions ;)