如何处理第三方库中的警告/提示？答案

【问题标题】：How to deal with warnings/hints in third party libraries?如何处理第三方库中的警告/提示？
【发布时间】：2014-04-07 13:38:07
【问题描述】：

我们使用 FastReport 生成报告。事实上，我们为访问源代码付费。

我们目前使用的是最新的稳定版 FastReport。虽然它对于我们的生产来说足够稳定，但每当我编译时，我都会看到：

[dcc32 Hint] fs_iinirtti.pas(369): H2443 Inline function 'TList.Remove' has not been expanded because unit 'System.Types' is not specified in USES list
[dcc32 Hint] fs_iclassesrtti.pas(656): H2443 Inline function 'TList.Remove' has not been expanded because unit 'System.Types' is not specified in USES list
[dcc32 Hint] fs_iclassesrtti.pas(1014): H2443 Inline function 'TList.Remove' has not been expanded because unit 'System.Types' is not specified in USES list
[dcc32 Hint] fs_idialogsrtti.pas(159): H2443 Inline function 'TList.Remove' has not been expanded because unit 'System.Types' is not specified in USES list
[dcc32 Hint] fs_igraphicsrtti.pas(252): H2443 Inline function 'TList.Remove' has not been expanded because unit 'System.Types' is not specified in USES list
[dcc32 Hint] fs_iformsrtti.pas(429): H2443 Inline function 'TList.Remove' has not been expanded because unit 'System.Types' is not specified in USES list

我不喜欢提示，更不用说代码中的警告了。现在，当然，H2443 提示可能不是最麻烦的提示，但我仍然想摆脱它。

幸运的是，如果它是我们自己的代码，H2443 修复起来很简单（只需添加它要求的引用）。但是即使在这种情况下我们可以访问第三方源代码，突然改变它感觉不合适。

所以我想知道：我应该等待 FastReport 的开发人员发布没有错误的新版本，还是应该自己修复它，然后在发布新版本时简单地覆盖我的源文件副本？

我想这个问题在技术上可以概括为如何处理第三方库中的提示/警告。我考虑过通知开发人员，但这不是开源/免费软件项目，因此修复不会持续几个月。

（公平地说，我应该提一下，以前的版本中曾经有更多的提示，所以至少有朝着正确方向的步骤。）

【问题讨论】：

你为什么要在这里发布这个？我认为最好联系 FastReport。
这个问题似乎是题外话，因为它是关于第三方图书馆的问题，应该发布在他们的支持网站上。
我以FastReport案例为例。但我很好奇它是如何处理的。所以基本上只是联系开发人员并等待？我想那是一个很好的答案。嗯，这是一个答案。
@Svip 我不会那样做。馊主意。然后，您将发布未针对其进行调试的代码。各种乐趣随之而来！
这是一个有效的问题。我对优秀的 TMS 组件包也有类似的问题。不断更新他们的最新产品可能不合适。

标签： delphi fastreport

【解决方案1】：

这是我在 Delphi 开发人员中经常看到的一个常见错误（许多第三方供应商也犯了这个错误）。为什么每次构建项目时都要编译 3rd 方库？

使用 DCU。将它们与源代码分开，并将您的库路径指向包含 DCU 的目录。这不仅加快了您的构建过程（因为它不会再次编译第 3 方源代码，而是使用 DCU），而且不会让您的项目充斥着来自第 3 方库的消息。

如果您想深入了解这些组件的源代码（根据我的经验，您通常不希望这样做），您可以将源代码添加到浏览路径中，甚至可以调试和发布您正在使用的 DCU。

【讨论】：

如果我有多个项目链接到不同版本的库怎么办？
@DavidHeffernan：如果其中一些库包含需要 IDE 注册的组件，那将是一个不值得羡慕的位置。
然后像之前可能所做的那样，将正确的库路径添加到项目中，并为不同版本的源设置正确的路径？去过也做过。我们甚至有一个完整的 git 存储库，其中包含第三方库（包括 dcu 和 bpls），我们可以在为我们产品的不同版本工作时（例如，当即将发布的版本使用某些第 3 方组件的新版本时）进行切换
我个人将所有文件添加到项目中。这样我所有的项目工作副本都是独立的。库路径是全局设置还是项目设置？顺便说一句，我在问问题以获取信息。听听别人如何做事很有趣。
库路径是全局的（每个项目在构建时都从其中获取其 dcu 和 pas 文件），项目中的相同选项称为搜索路径，然后是浏览路径（通常是您放置包含源文件的目录的位置，以便您可以 ctrl+单击并打开它们）。所以是的，当我说“将其放入项目的库路径”时，我是不正确的，因为我的意思是“将其放入您的搜索路径”。

【解决方案2】：

这是我的工作：

第三方库在本地获得自己的源代码控制存储库。如果它们是开源的，我会尝试克隆上游存储库。如果不是，则每个新版本都是供应商分支中的新提交。我修复的任何提示/警告/错误都会提交到不同的分支并发送给供应商。如果他们接受修复，那就太好了！如果没有，那么我自己仍然有补丁，新的上游版本只需合并到我自己的分支中。

【讨论】：

【解决方案3】：

基本上有两种方法可供您选择。

如果您准备更改源代码，请这样做。与其解决导致警告/提示的问题，不如禁用警告/提示。这是解决问题的侵入性最小的方法。第三方库很可能会附带一个包含文件。您可以向该包含文件添加指令以抑制警告/提示。每次交付第三方代码的新版本时，使用修订控制可以轻松地重新应用这些修改。
如果您不能或不想更改源代码，您唯一的选择是请求开发人员解决问题。

【讨论】：