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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
