[fpc-devel] Preprocessor (was: FPC Branches)

[Hans-Peter Diettrich]

Jonas Maebe schrieb:

>> The stand-alone preprocessor code ($PreprocWrite, commandline
>> option -m) does not compile since a long time. I could it make work
>> again, and already supplied the according patch in Mantis.
> 
> 
> And as I replied in mantis two days ago, a) that option is not
> documented in the help page because it never worked in the first
> place (I don't even know what its purpose is)

You simply could have tried, and looked at the output. It does what 
every preprocessor does, i.e. execute the preprocessor directives and 
output the remaining parts (except comments) of the source file.

> b) the code for that
> option predates svn (it was written more than 10 years ago), which is
> why it's in trunk rather than in a separate branch

Why a branch for a simple function of the compiler?

> c) even if that
> code merits fixing and enabling, the patch you submitted cannot be
> applied for several reasons (detailed in the mantis bug report)

I'm really stumped by your detailed "reasons" :-(


Citing from your reply on Mantis:

 > The -m option and -dpreprocrewrite has never worked.

Now it does - so what?

 >I'm not even sure what the purpose of that code is. What does it do?

What a preprocessor does: remove comments and excessive whitespace, 
include files and handle conditional directives. The remaining code is 
written to an file.

 > And what can the compiler do after this patch?

It can output the preprocessed file, instead of an object file. In that 
file one can see which code remains, after the conditionally excluded 
parts have been removed. Very helpful when complex nested conditions and 
defines are used.

 > This patch seems to do a lot more than simply fix an undocumented and 
 > never-finished command line parameter, and the comments you added 
seem > to indicate that this code is far from finished (lots of question
 > marks and TODO comments as you also mention above).

The questions arose from the missing (detailed) description of the 
preprocessor. They are easy to answer, but deserve an consent about the 
correct answer (desired behaviour).

 > Also, adding a lot of commented-out code is not good practice, it 
only > makes the code harder to read.

I've left the original code for the case that somebody wants to know 
more about my changes, before adding it permanently to the trunk.

 > This is not necessarily an improvement:
 > - from the old Objects to the current Classes,

This is not an improvement, it simply is a requirement. If you had 
studied the code, or only had compared the old outcommented code with 
the new one, you had found out easily that the compiler nowadays uses 
Classes, where it used Objects in the time the preprocessor was written.

 > This is also wrong:
 > fixes a scanner problem (# 10 never occurs on Windows?)

How can you decline? Have you debugged the code, as I did? :-(

 > Please also always submit separate patches for separate things, e.g.
 > fixes TPreProcFile (missing "override" on destructor)
 >
 > This is unrelated to the rest of the patch (it's also harmless, but
 > it's indeed nicer to correct it)

Please look up the declaration of TPreProcFile, and find that it is 
enclosed in $IFDEF PREPROCWRITE. It consequently *is* related, and the 
"override" is not harmless, because a destructor without "override" is 
never called by Free. Please test yourself, if you don't believe me.

And it's not my fault that the preprocessor related parts are scattered 
accross multiple units, and that the scanner is also involved. I only 
made the preprocessor compile in a first step, and then fixed the 
remaining issues, that prevented it from working properly. Should I 
supply two or more patches, which only make sense when applied together?


I hope that you have another closer look at the code, and adjust your 
wrong assumptions.

Regards
DoDi