2

I plan to modify some of the sources (i.e. in ...\Embarcadero\Studio\15.0\source) to fix some bugs. How do I compile them so I can update what's in ...\Embarcadero\Studio\15.0\lib?

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
John Mac
  • 2,530
  • 4
  • 24
  • 30
  • 1
    Everything in `lib` is up to date with what's in `source`. What are you actually trying to accomplish? (Why do you think you need to do this?) – Ken White Dec 18 '14 at 00:43
  • Because "Everything in lib is up to date with what's in source" isn't (won't be) the case. There are some bugs I want to fix and don't want to have to manage private copies of the fixed sources. Rebuilding the libraries seems simplest, unless you have a better suggestion that avoids having to remember & take account that I changed X at some point in the past - that would work too. – John Mac Dec 18 '14 at 00:51
  • 1
    The problems with that are twofold: 1) Future updates won't install, because the source files won't match the checksum, and 2) you won't be able to use runtime packages in the future, because your license prohibits rebuilding/redistributing those, so code that uses packages won't function the same as code that doesn't. (Well, there's a third: Upgrading to a new version of Delphi in the future would mean you have to reapply any changes to that new version.) The proper way to do this would be to put a copy of the source you want to change in your project folder and modify that copy. – Ken White Dec 18 '14 at 00:53
  • 1
    What Deltics describes is one way. If you can change the behaviour with a run time hook/patch that is even better in my view. – David Heffernan Dec 18 '14 at 07:07
  • @David, the problem with runtime hooks/patches is that they are far less likely to break at compile time when a new version of Delphi comes along. A patch is introduced, people move on, time passes (often a LOT of time) and then in a new version of Delphi you get strange new bugs reported which takes someone time to investigate to uncover the patch that is causing the problems with the new version. A copy of a VCL unit often results in immediate compile time issues with a new Delphi version or *no* undesired side effects (apart from not getting the benefit of the new version of the unit). – Deltics Dec 18 '14 at 20:27
  • @David cont... runtime patches can make allowance for previous, existing versions of the unit to ensure backward compatibility. But by definition the patch author cannot know how any future version of the unit (or other units) might affect their patch, and is severely limited in their ability to mitigate that possibility. – Deltics Dec 18 '14 at 20:28
  • @Deltics My patches are centrally located in a unit that will only compile for specific values of CompilerVersion. It's usually harder work to re-apply the changes to a source unit than to check that the patch still works. Then there were those Delphi versions for which the trick in your answer doesn't work. Covered here on SO. – David Heffernan Dec 18 '14 at 20:31
  • @Deltics Severely limited. Not at all. Trivially easy to arrange. As per my previous comment. Just issue compiler error in case of unrecognised compiler. – David Heffernan Dec 18 '14 at 20:32
  • The Delphi versions not supporting modifying the source presumably being Starter (no source) ? But I wonder how far you will get trying to implement a runtime patch when you can't see the source of the thing you are patching. Without the source, neither of these approaches is really viable. But equally in either case you can (practically if not strictly 'legally') use a solution (patch or modified VCL unit) from someone else. :) – Deltics Dec 18 '14 at 21:00
  • @Deltics No. Some of the recent XE versions. XE6. My guess is Emba shipped dcus that didn't match the pas files. http://stackoverflow.com/questions/24145214/can-i-modify-a-constant-in-the-rtl-class-system-classes-tstream-and-rebuild-it-a – David Heffernan Dec 19 '14 at 07:45
  • Ah, I see. Useful to know, should someone ever ask me about XE6. – Deltics Dec 19 '14 at 22:08

1 Answers1

14

The source that is provided with Delphi can be recompiled, but the DCU's (pre-compiled binaries) that are shipped with the product cannot be. The DCU format specifically includes a marker to indicate that a DCU should not be replaced by a recompilation of the source. This marker is only set for the DCU's shipped with the product (I'm not aware of any mechanism for setting this marker in your own units).

This is why there are two sets of DCU's - one for DEBUG and one for non-debug builds. And this is why you have a project option specifically to control which set of DCU's your project is linked with. Your own units are compiled with or without debug info, according to your compiler settings at the time. But the RTL/VCL units provided are not recompiled, so you have to choose whether to use those pre-compiled with DEBUG or without.

Still with me ? Good. :)

The reason you are prevented from recompiling the RTL/VCL units is that doing so poses a serious risk. The packages containing the design-time components (also shipped with the product) are obviously compiled with a specific version of the sources (those included with the product) if if these were to be changed then the package contents would no longer correspond with the sources on disk, making debugging potentially difficult.

Furthermore, even if allowed, it would mean that you would be limited in what you could achieve by modifying the source. You could not for example introduce new (or remove existing) published properties or change the declared type of existing properties as to do so would almost certainly break the persistence of existing form files containing the components involved.

However, having said all that, it is still possible to make selective changes.

The trick is to force your project to compile with a copy of the RTL/VCL unit that you wish to modify. The simplest way to achieve that is to place a copy of that unit in the same location as the DPR. A more reliable way however would be to keep a separate, specific folder containing all such units which you may modify and to add this folder to the search path of your IDE or of specific projects.

You must be sure to observe a Golden Rule however, which is that any changes you make cannot and must not modify the interface section of the units involved.

If you do, then you will find that other units, which you have not modified, will refuse to link to the modified units when you attempt to compile your project.

But as long as you stick to this rule and only make changes to the implementation section of the units, then you should be OK. Even within these constraints this should allow enough scope to fix some of the bugs you have in mind.

Of course, you also have to live with a somewhat more complicated build environment and potentially deal with merging revisions from subsequent releases of the RTL/VCL units that you modify as new releases of Delphi become available. Whether this is worth it in your case really depends on how severe the bugs are that you are intending to deal with. You may find it easier to deal with these bugs by working around them, rather than trying to fix them directly (if possible).

Deltics
  • 22,162
  • 2
  • 42
  • 70
  • I +1'd by the time I got to reading "A more reliable way however would be to keep a separate, specific folder containing all such units which you may modify and to add this folder to the search path of your IDE or of specific projects." – Jerry Dodge Dec 18 '14 at 02:11