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

[Michael Van Canneyt]

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

   {$IFDEF FPC_HAS_MYFEATURE}
   // Code specific to your feature
   {$ENDIF}

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

    def_system_macro('FPC_HAS_MYFEATURE');

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.

Michael.