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


--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply via email to