[fpc-devel] External tools API

[Hans-Peter Diettrich]

Some notes on the compiler API/interface for external tools, based on my
observation of the ppudump program.

When this API *really* shall be target independent, as some people
believe it already is, it deserves some fixes. Every copy of
declarations, out of compiler units into external tools, indicates
broken independence. In a clean API all these declarations have to be
moved into other units, that do not introduce unwanted dependencies when
used by external tools.

In so far I consider the ppudump dependency problem solved, the rest is
the job of the maintainers of either the external tools or their
compiler interface.


About the design of "independent" tools, Michael annotated my ppudump
patch like this:
"This patch goes against what ppudump was designed for initially: to be
independent of the compiler, so as to be usable for other tools."

The new ppudmp unit logic is as independent from the compiler as the
ppudump program has been. As mentioned before, true compiler
independence requires that all those declarations and procedures, that
are designed/acknowledged for use by external tools, have to reside in
specific units (to be documented), which do not introduce unwanted
compiler (target...) dependencies.

Copy&paste of declarations or entire procedures, out of the compiler
units into external tools, can lead to broken tool functionality. Some
concrete examples of what can happen as soon as the compiler
declarations start to differ from their copies, as found in the ppudump
code:

1) The tools erroneously report errors, as soon as the processed data
contain values that are yet unknown to the tool.

2) The tools can not interpret correctly the rest of the data, when they
simply ignore unknown data sections, instead of skipping properly over
them. When such sections are subject to conditional compilation, only
their *creation* can be made conditional, while every occurence in data
files has to be handled unconditionally, and herefore all related
declarations also must be available unconditionally.

3) The same string constants should be used for enumerated types, in
both the compiler and external tools, so that typos can be detected
during normal compiler development. When e.g. a type is reported as
another one (signed instead of unsigned), this bug is hard to find when
the output is generated from string literals in external tools.

DoDi


P.S.: In ppudump4.patch I could remove further dependencies, except for 
globals.tsettings. Until somebody can move this symbol somewhere else, 
no further unit dependencies can be added to globals.pas, so that other 
global variables have to be moved out of this unit.