Conditional compilation for various Delphi versions

[dummzeuch 1506]

If you are maintaining a library, component or plugin for various Delphi versions you will sooner or later hit a point where it becomes necessary to have different code for some of them.

Some examples are:

• The constants faTemporary and faSymlink are only declared in Delphi 2009 and later, so you have to declare them yourself for older versions.
• Some Open Tools API function have bugs in some versions so you have to implement a workaround.
• Some classes or functions have been added to later versions of the RTL so you need to implement them yourself for older versions, but you don’t want to use these implementations for newer versions

The traditional way of masking code for some Delphi versions is using the VERxxx symbols which the compiler defines, where xxx is the compiler version multiplied by 10.

 

Note that the compiler versions started with Turbo Pascal, not with ...

 

https://blog.dummzeuch.de/2018/12/02/conditional-compilation-for-various-delphi-versions/

[Primož Gabrijelčič 223]

In my opinion, the best solution is to use jedi.inc and then IFDEF against features (SUPPORTS_OVERLOAD, SUPPORTS_GENERICS, HAS_UNIT_VCL_THEMES ...) and not against Delphi versions.

[Stefan Glienke 2009]

7 hours ago, Primož Gabrijelčič said:

IFDEF against features

If possible - often enough you ifdef because of bugs or workarounds. I usually ifdef using the defines from jedi.inc and put a comment to the reported issue that I ifdef for.

[Primož Gabrijelčič 223]

And sometimes fighting with bugs becomes too much and you just remove some functionality for specific subset of compilers. That's why OTL uses OTL_Generics and OTL_GoodGenerics.

[Rollo62 538]

I personally use ifdef as modularization option of common behaviours, for different customers or versions,

e.g. in a common configuration file (*.inc normally).

What I mean here is for example the support of special custom hardware modules (e.g. for connection to special hardware which is supported).

 

To make the whole process more readable, I personally use a special signature for my ifdefs very often,

which makes the whole status and situation very readable and clear for the status of switching ON and OFF.,

{$DEFINE _X_USE_MODULE_A}
{$DEFINE _X_USE_MODULE_B}
{$DEFINE ___USE_MODULE_C}
{$DEFINE _X_USE_MODULE_D}
{$DEFINE ___USE_MODULE_E}

...

{$IFDEF _X_USE_MODULE_A}
...
{$ENDIF _X_USE_MODULE_A}

I know that mostly the notation of {.DEFINE Module_A} is used for switching off conditionals, but I very much dislike this for poor readability,

especialy if you have switches for many similar options, like in above sample.

 

This is just a possible, different way to to defines (which I have never seen anywhere else before, but this I don't care).

Maybe somebody likes such "talking" defines too.

 

 

 

[Remy Lebeau 1405]

On 12/2/2018 at 4:51 AM, dummzeuch said:

The traditional way of masking code for some Delphi versions is using the VERxxx symbols which the compiler defines, where xxx is the compiler version multiplied by 10.

Actually, since Delphi 6+, the preferred method is to use $IF with the CompilerVersion and/or RTLVersion constants, instead of using $IFDEF with the VERxxx conditionals.

[dummzeuch 1506]

6 hours ago, Remy Lebeau said:

Actually, since Delphi 6+, the preferred method is to use $IF with the CompilerVersion and/or RTLVersion constants, instead of using $IFDEF with the VERxxx conditionals.

Your definition of "traditional" obviously is different from mine. Maybe I'm just older.

In my blog post I actually continue:

> An alternative is the {$IF } compiler directive which can test for arbitrary Boolean expressions [...] It was added to the Delphi compiler in Delphi 6, so it covers quite a few Delphi versions. <