3

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.)

Svip
  • 2,958
  • 3
  • 22
  • 33
  • Why are you posting this here? I think it is better to contact FastReport. – Toon Krijthe Apr 07 '14 at 13:40
  • This question appears to be off-topic because it is about a problem in a third party library and should be posted at their support site. – Toon Krijthe Apr 07 '14 at 13:41
  • I used the FastReport case as an example. But I was curious to how it was dealt with in general; so basically just contacting the developers and wait? I guess that's a fine answer then. Well, it's an answer. – Svip Apr 07 '14 at 13:44
  • It is often the only option. Because if you are fixing it yourself, you will be in trouble, when the library is updated. An alternative is to use the compiled library so you won't see the hints and warnings. – Toon Krijthe Apr 07 '14 at 13:47
  • Can I compile against the compiled library while still using their source code while debugging? – Svip Apr 07 '14 at 13:48
  • Yes, that's what the browse path is for. – afrazier Apr 07 '14 at 13:48
  • 1
    @Svip I would not do that. Bad idea. Then you are releasing code that you did not debug against. All sorts of fun ensues! – David Heffernan Apr 07 '14 at 13:57
  • 2
    It's a valid question. I have similar issues with the excellent TMS Component Pack. It might not be appropriate to keep updating to their latest offering. – Brian Frost Apr 09 '14 at 13:42

3 Answers3

9

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.

Stefan Glienke
  • 20,860
  • 2
  • 48
  • 102
  • What if I have multiple projects that link to different versions of the library? – David Heffernan Apr 07 '14 at 15:50
  • @DavidHeffernan: That's an unenviable position to be in if some of those libraries contain components that require IDE registration. – afrazier Apr 07 '14 at 16:27
  • 1
    Then you add the proper library path to the project as you probably did before with setting up the proper path to the sources of the different versions? Been there done that. We even have an entire git repository that contains third party libraries (including dcu and bpls) that we can switch when working for different versions of our product (like when the upcoming release uses a new version of some 3rd party component) – Stefan Glienke Apr 07 '14 at 16:27
  • Personally I add all the files to the project. That way all my project working copies are self contained. Is library path a global or project setting? By the way, I'm asking the questions for information. It's interesting to hear how others do things. – David Heffernan Apr 07 '14 at 16:33
  • @afrazier It tends not to be a problem for me because maintenance dev as we do it seldom requires work in the designer. Tends to be code only. – David Heffernan Apr 07 '14 at 16:35
  • 2
    Library path is global (where every project takes its dcu and pas files from when you build it), the same option in a project is called search path and then there is the browsing path (that is usually where you put the directories that contain your source files so you can ctrl+click and open them). So yes I was not correct when I said "put it to the library path of your project" as I meant "put it into your search path". – Stefan Glienke Apr 07 '14 at 16:36
5

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.

afrazier
  • 4,784
  • 2
  • 27
  • 30
2

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.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490