[fpc-devel] MakeSkel and FPDoc projects

Hans-Peter Diettrich DrDiettrich1 at aol.com
Fri Dec 16 17:48:09 CET 2011

When MakeSkel shall use FPDoc projects, this can be achieved by adding 
something like:

procedure LoadProject(const Arg: string);
   ProjectName := Arg;
   Project := TFPDocProject.Create(Nil); //owner component?
   With TXMLFPDocOptions.Create(Project) do
       if (PackageName = '') and (Project.Packages.Count > 0) then
         PackageName := Project.Packages[0].Name;

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)
         Pkg := nil; //project not usable
       if assigned(Pkg) then begin
         //extract further options?

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


More information about the fpc-devel mailing list