[fpc-devel] Macro Processing (pre-processor)
fpc at mfriebe.de
Tue May 17 14:38:35 CEST 2011
On 17/05/2011 13:19, Joerg Schuelke wrote:
> Am Tue, 17 May 2011 12:59:57 +0100
> schrieb Martin<fpc at mfriebe.de>:
>> Based on this. The question is does the benefits really outweigh the
>> cost ?
> Of course not. The much writing shows there is only Hans-Peter possibly
> for a try. I thought that some of the reasons where only educational ;-)
Going for educational.. or theoretical...
There is another idea => which would still make some of this possible.
but which I don't know if it would be worth it. ...
The macro processing (that has been proposed before) can be done by a
The draw-backs may be solvable. (assuming I am correct about point 3)
A pre-processor would create temporary files, with the macros expanded.
It has to be agreed, that those temp files, are only for the purpose of
compilig, and must never be touched/edited by a person (since changes
would be lost the next time the pre-processor runs). In fact those temp
files should be deleted right after compilation.
This does affect:
1) the ability of fpc to check if a ppu needs to be recompiled, because
the source file known to fpc doesn't exist
2) the output of line numbers for compile errors and warnings
3) line numbers in debug info
1: would be solved by the pre-processor, that would to the check, and
put a new temp file in the place, expected by fpc
2: can be solved easily. The pre-processor has to run fpc, the
pre-processor reads the fpc output, and maps line numbers to the correct
3: Could be solved by compilng to asm. (I assume): fpc must write the
info for the assembler how the line numbers map. so they could be
corrected. And the assembler can be called once line numbers are corrected
It is quite some work though. But you do not need to touch fpc at all.
More information about the fpc-devel