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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
