How to deal with warnings/hints in third party lib

问题:

We use FastReport for report generation. Indeed, we pay for access to the source code.

We are currently using the latest stable version of FastReport. And while it is stable enough for our production, whenever I compile I see this:

[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

I am not a fan of hints, much less warnings in my code. Now, of course, a H2443 hint is perhaps not the most troubling of hints, but I'd still like to get rid of it.

Fortunately, had it been our own code, a H2443 is trivial to fix (just add the reference it is asking for). But even though we have access to the third party source code in this scenario, it feels inappropriate to suddenly alter it.

So I wonder: Should I just wait for the developers of FastReport to release a new version without the error or should I fix it myself and then simply overwrite my copy of the source files when a new version is released?

I suppose this question could technically be generalised to how to deal with hints/warnings in third party libraries. I thought about notifying the developers, but this isn't an open source/free software project, so the fix won't be for months.

(In fairness, I should mention, that there used to be far more hints in previous versions, so at least there are steps in the right direction.)

回答1:

This is a common mistake I often see amongst Delphi developers (and also many 3rd party vendors do that wrong). Why are you compiling the 3rd party library every time you build your project?

Use DCUs. Separate them from the source and point your library path to the directory that contains the DCUs. That not only speeds up your build process (because it does not compile the 3rd party sources again but uses the DCUs) it also does not flood your project with messages from 3rd party libraries.

If you want to step into the source of these components (you often don't want that from my experience) you can add the sources to the browsing path and even make debug and release DCUs that you are using.

回答2:

Here's what I do:

3rd party libraries get their own source control repository locally. If they're open source, I try to clone the upstream repository. If not, each new version is a new commit in the vendor's branch. Any hints/warnings/bugs that I fix are commited to a different branch and sent to the vendor. If they accept the fix, great! If not, then I still have the patches myself and new upstream versions simply get merged into my own branch.

回答3:

There are basically two approaches that you can take.

1. If you are prepared to change the source code, then do so. Rather than addressing the issue that leads to the warning/hint, just disable the warning/hint. That's the least invasive way to tackle the problem. Most likely the third party library will come with an include file. You can add directives to that include file to suppress warnings/hints. Use revision control to make it easy to re-apply these modifications every time you take delivery of a new version of the third party code.

2. If you cannot, or do not want to, change the source code, your only option is to petition the developers to fix the problem.