[fpc-devel] FPDoc imports

[michael.vancanneyt at wisa.be]

On Wed, 1 Feb 2012, Hans-Peter Diettrich wrote:

> 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.

Why do you need this ? You make it quite complicated.

All you need is a FindModule(Const AName,AFileHint : String) : TPasModule call 
in TPasTreeContainer which must be overridden in a descendent (such as TFPDocEngine). 
The default implementation returns nil.

This call can search the module list if it has one. If it doesn't find it, 
it can then decide to parse it anyway and return the just-parsed instance.

All the parser needs to do is call FindModule whenever it encounters a unit
in a uses clause; The rest will happen then automagically.

Then you can create a TPasTreeContainer descendent called TModulesPasTreeContainer 
which keeps a list of modules and which implements FindModule with the above described 
recursive mechanism.

The FPDoc engine can then be a descendent of that class.

The above is what I was planning to implement. It is simple and will do the
job, plus, for circumstances where there is no need for the recursive
mechanism, nothing changes.

Michael.