Frank Heckenbach wrote:
CBFalconer wrote:
Frank Heckenbach wrote:
GPC currently uses a stand-alone preprocessor (gpcpp) that is derived from the C preprocessor and shares many of its features.
I plan to integrate it into the compiler which would follow gcc's example (not so important, though), maybe make it a little faster (not very much, I guess, since preprocessing in general doesn't take very long), solve some problems (e.g., the `--needed-option' ugliness, mostly on MIPS) and allow for further improvements.
... snip ...
You can always go further by integrating things with the symbol table, etc., but is it worth it? The resultant input language is neither fish nor fowl.
I don't think so. It should still be possible to see the preprocessed source (with `-E'), and of course, no-one is forced to use the preprocessor.
My own view is that there are already too many exceptions and extensions in gpc, and once something is added it is hard to remove, because there is always a group that uses everything.
That's already the case with the current preprocessor. Actually, I'm trying to make it simpler, not more complex.
Don't misunderstand, I wasn't arguing for using m4, just pointing out that it exists. Actually, on further idle thought (none of this is especially well thought out) maybe the integrated preprocessor is the way to implement the Delphi constructs. The philosophy of the triple system, GNU, 10206, 7185 seems to be firmly established. By banishing most Delphi and TP extensions to such a preprocessor it might be possible to keep the main thing cleaner.