[fpc-devel] FPDoc imports

[Hans-Peter Diettrich]

Sven Barth schrieb:
> Am 31.01.2012 14:42, schrieb Hans-Peter Diettrich:

>> I still wonder why the number of units in the imported RTL package
>> increases over time. Initially it contains 7 modules, and 38 modules in
>> the end, where the RTL currently consists of 46 units. 6 of the initial
>> modules contain classes, but I couldn't find the 7th module "iostream"
>> anywhere, which is the first module in the list.
> 
> The only "iostream" unit I'm aware of is in packages/fcl-base/src.

Right, and it somehow found its way into the rtl package. I'll know more 
  soon.

In the meantime I found a solution for the input files order, by 
recursive compilation. Unfortunately I couldn't test it right now, for 
several reasons. Most important is the large number of affected units, 
which may make some people reject such an patch immediatly. So let me 
explain first what I implemented so far, and what remains to be done.

First the storage format of the fpdoc Inputs is not really handy, every 
commandline has to be parsed for the input filename, from which the unit 
name can be extracted. It would help when the storage format would be 
modified, so that the entries can be found with IndexOfName, as 
implemented in FPDocManager. This is what I didn't implement yet.

Next problem is the separation between parser, engine and the fpdoc 
creators, which are involved in finding the used units in the current 
package. Herfore I added a method AddModule to the engine, which adds 
the newly created module to the Modules list, and also notifies fpdoc of 
the addition by an OnAddModule callback. Then the creator can put the 
TPasModule into Inputs.Objects, to signify that it is or has been parsed.

When a uses list is parsed, the parser asks the engine to search for an 
alredy parsed unit (FindModule). Since the engine doesn't know about 
package Inputs, it uses another callback to get the unit from the 
creator out of Inputs.Objects. When no module has been parsed, the 
creator starts another parser for this unit, like in 
CreateDocumentation(). This routine currently parses all Inputs 
sequentially, and has to be modified to skip those entries which already 
have an TPasModule unit assigned.

Much work could be avoided when TPasPackage uses a TStringList for its 
Modules. Then this list could be copied from the creator Inputs before 
the units are parsed, and all searching for the units in a package can 
be done inside the package, without references back to the engine and 
creator. This solution also would replace beforementioned callbacks, so 
that the parser still can be used for other tasks, too.

Please let me know what you think about my ideas. Once I know how to 
proceed, I can present a solution soon.

DoDi