When MakeSkel shall use FPDoc projects, this can be achieved by adding
something like:
procedure LoadProject(const Arg: string);
begin
ProjectName := Arg;
Project := TFPDocProject.Create(Nil); //owner component?
With TXMLFPDocOptions.Create(Project) do
try
LoadOptionsFromFile(Project,Arg);
if (PackageName = '') and (Project.Packages.Count > 0) then
PackageName := Project.Packages[0].Name;
finally
Free;
end;
end;
Handling of the InputFiles and DescrFiles can be added similar to above
handling of the (default) PackageName, e.g.
if assigned(Project) then
//the package *must* be part of the project
Pkg := Project.Packages.FindPackage(PackageName)
else
Pkg := nil; //project not usable
if assigned(Pkg) then begin
InputFiles.Assign(Pkg.Inputs);
DescrFiles.Assign(Pkg.Descriptions);
//extract further options?
end;
DocumentPackage(...)
Since new description files should be added to the project, I'd suggest
that MakeSkel uses a Project and the lists as stored in it, instead of
the InputFiles and DescrFiles variables. This change only affects the
program code, which passes these lists to DocumentPackage.
Then the created skeletons can be added to the DescrFiles list, and the
updated project can be saved on exit.
Furthermore it should be possible to process a single module from a
project package, for which e.g. a skeleton shall be created, or which
should be checked for errors by fpdoc. This requires that the --input
value selects one of the input files in the project. This can be
simplified by splitting the InputFile strings, into File and Options
parts, as is already done in the project files. The stringlist
representation could e.g. look like <file>=<options>, so that
IndexOfName can be used to select an entry, and the "=" is replaced by
an space before the entry is passed to the worker code. Then also
another option --unit=<unit-name> can be used to select the specific
input file to process. Then the stringlist representation also can be
changed to <unit-name>=<existing --input descriptor>, and
Values[<unit-name>] can be passed to the worker code.
Currently FPDoc scans the commandline for a project first, before
parsing the other options. This extra handling could be removed, with
the effect that options before the --project option are defaults, which
are overridden by the project settings, while options after --project
override the project settings. This consideration applies to all
programs, which accept an fpdoc project.
I'm willing to provide "clean" patches, once I know which of above
suggestions to implement. This would be much easier when the worker code
would be moved out of the program files, into dedicated units. Then the
modifications to the program files can be separated from modifications
to the worker unit(s).
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
