Compiler option for “Use Debug DCU's”?

Question

In a component I am writing, I want to include automatic detection of registered image formats , but it is a solution that only works if the Use Debug DCU's compiler option is disabled.

What I really would like to know is an alternative for this solution that does not involve compiler option dependency.

But for the time being, I just want to know how I can check at runtime whether the Use Debug DCU's compiler option is set.

Answer 1

There is no reliable way to get that information at runtime

The Use Debug DCUs compiler option only switches the search path; What the compiler will eventually find there is unknown. An (misguided) user might have copied the Release dcu's over the debug directory, or vice-versa.

Even without misugided users, one might have some files added to the project (and compiled with the project) in order to include some bug-fix. For example, if the user has the Graphics.pas added to the project, does a release/no-debug build, but keeps the Use Debug DCU's compiler option, then the Graphics.dcu that's actually linked is not a debug build, because it's re-built with the executable. So you get a "mixed" bag of debug and non-debug dcus.

You could attempt detecting the presence of debug information related to certain objects or methods, but this too would be unreliable: If you use "Build with Debug Dcus" but then set "Debug Information" to false, then you're essentially throwing away the debug information so you can no longer look for it.

But that linked code fails on Debug DCU's

The code from the GLScene project is not a good hack, it uses hard-coded offsets into the code for the TPicture.RegisterFileFormat , then continues to use hard-coded offsets to get the address of the global FileFormats variable (doesn't call the GetFileFormats routine). Too many magic numbers in there!

My first though was to compare the TList identified using the GLScene method to the TList I've identified, but guess what: On my machine there was no problem, both routines got the same result, in both circumstances. On my machine the GLScene , ugly as it is, is not broken with Debug DCUs.

I've even tried "fingerprinting" some of the rtl/vcl units (SysUtils, Graphics, Classes); I made a list of all the public classes, generated some code that uses RTTI for each method in each class and dumps the first 1024 bytes of the code to a string file. Ran that program with Debug DCUs and non-Debug DCUs and I got the same result . My text files contain the fingerprints for some 3500 methods!

Not a good idea

Since that option doesn't really affect the way the compiler compiles (only what the linker links), creating code that depends on this option is highly unreliable and not a good idea. This only affects low-level hacks , and you don't want low-level hacks that might crash your application under circumstances that are absolutely out of your control.

The only true option is replacing the potentially failing hack with one that's not going to fail (or at least fails in controllable ways).

Answer 2

As Ken comments , there is probably no way to detect the path change this compiler option involves. The command line compiler documentation does not mention a compiler switch, thus meaning that it simply does not exist. Without compiler switch, it isn't possible to check whether that compiler option is set

---

...but it is a solution that only works if the Use Debug DCU's compiler option is disabled.

If only works means that it otherwise results in an exception, then you could use the following alternative:

try
  // AutoDetectRegisteredImageFormats
except
  // Handle case when Use Debug DCU's is on
end;