[fpc-pascal] Compiler internals. Changing dynamic arrays format
denisgolovan
denisgolovan at yandex.ru
Wed Apr 13 12:39:20 CEST 2022
> 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.
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}
{$IFDEF FPC_CYCLELEVEL1}
// CYCLELEVEL1 compiler builds our sources
def_system_macro('FPC_CYCLELEVEL2');
{$ENDIF}
{$IFDEF FPC_CYCLELEVEL2}
// CYCLELEVEL2 compiler builds our sources
def_system_macro('FPC_CYCLELEVEL3');
{$ENDIF}
{$IFDEF FPC_CYCLELEVEL3}
// CYCLELEVEL3 compiler builds our sources
def_system_macro('FPC_CYCLELEVEL4');
{$ENDIF}
... somewhere in options.pas should be enough.
Or maybe there is already some existing / more reliable way?
-- Regards,
Denis Golovan
More information about the fpc-pascal
mailing list