[fpc-devel] FPDoc improvements

Hans-Peter Diettrich DrDiettrich1 at aol.com
Sat Jan 28 11:50:05 CET 2012


Marco van de Voort schrieb:
> In our previous episode, Mattias Gaertner said:
> 
>>> [...]
>>> For the --input-dir there is an extra reason: the order of files is important.
>>> Just like in the compiler, which must compile dependent units first, fpdoc
>>> should first document dependent units. It currently does not know how to do 
>>> this by itself.
>> Contrary to the compiler the fpdoc files can refer freely to each other.
>> Is the above "should first document dependent units" your preference
>> or is there really a reason? 
>> What if I need an alphabetical or logical order (e.g. the most
>> important at top)?
> 
> The parsing order and the order in the overview pages should then be
> decoupled (e.g. by a sorting event that is configurable)
> 
> The parsing order is mandatory even. I still have to research the
> consequences for latex. The latex backend currently doesn't seem to suffer from
> order problems which is probably means it is vulnerable to duplicate
> identifiers.

Linear documents IMO should follow their own rules, which make the docs 
readable. A simple concatenation of element descriptions is a poor man's 
solution, far away from e.g. the Delphi(7) PDFs. I'd suggest a skeleton, 
containing the document structure and verbose parts, and include 
instructions for the XML elements, overviews and tables, created e.g. 
for class members.

> The html backend however isn't free from this, but has the limitation that
> it only suffers from duplicate identifiers wrt already parsed units and .xct
> modules.

Isn't this a matter of properly linking identifiers, declarations and 
descriptions to each other? What detailed information does the PParser 
need about identifiers declared somewhere else?

DoDi




More information about the fpc-devel mailing list