[fpc-pascal] Compiler internals. Changing dynamic arrays format

Michael Van Canneyt michael at freepascal.org
Wed Apr 13 12:53:25 CEST 2022

On Wed, 13 Apr 2022, denisgolovan via fpc-pascal wrote:

>> On 2022-04-13 00:34, denisgolovan via fpc-pascal wrote:
>> Your comment about conditional defines goes in the right direction -
>> basically:
>> 1) Separate your changes into parts affecting the compiler behaviour
>> (e.g. the changes impacting the compiled structures and code, etc.) from
>> changes needed because of the changed behaviour (i.e. use of your new
>> features within the RTL and/or the compiler, modified versions of code
>> working with the newly / differently compiled structures, etc.).
>> 2) Create a conditional define for your new changes - this new define
>> would be enabled within the compiler behaviour affecting changes.
>> 3) Make your changes resulting from the changed behaviour (either in the
>> RTL, or in the compiler) enabled only when the new conditional define is
>> enabled.
>> If you do this, you should be able to use the standard makefiles without
>> any changes (e.g. "make compiler_cycle", etc.).
>> Tomas
> Ok. It's good then.
> I'd like to know about the actual CYCLELEVEL logic implementation details.
> So far I haven't found any explicit conditional define related to cycle levels.

They don't exist.

> I assume something like:
>  {$IF not defined(FPC_CYCLELEVEL1) and not defined(FPC_CYCLELEVEL2) and not defined(FPC_CYCLELEVEL3)}
>    // previous version compiler builds our sources
>    def_system_macro('FPC_CYCLELEVEL1');
>  {$ENDIF}

What Tomas means is that you do your changes in

   // Code specific to your feature

and in the part where all macros are defined (normally options.pas), do a


This way, when you start with the normal compiler, your code will not be
included, but the first-level compiler will, when compiling, have the FPC_HAS_MYFEATURE
defined, and your feature code will be included.


More information about the fpc-pascal mailing list