I just tried to extend the programs in the fpdoc folder, morphing the program files into unit files by conditional compilation:

{$IFDEF DoDi}
unit ...;
interface
{$ELSE}
program ...;
{$ENDIF}

etc., no problem so far.

Then I wrote my own MkSkel program, using MakeSkel as a unit. Also fine :-)

Then I tried to extend the functionality with wildcards, what also worked fine after some more adjustments. E.g. I added an OnOption handler, that handles additional commandline options, which are not recognized by the ParseOption procedure.

BTW is it really required to add "-Fi.", so that the parser finds include files in the current directory (of the unit file)?

When I tried to create the skeletons for all *.pas and *.pp files, I stumbled across exceptions with missing interface sections. It would be nice to prevent such exceptions, when MakeSkel tries to process an program file, whereupon AModule.InterfaceSection is Nil!

Then I was very astonished about "No Interface section in MakeSkel" messages, and it took me some time to find the bug in UnitDiff.pp, which contains

   program MakeSkel;

instead of

   program *UnitDiff*;

Please fix this glitch.

When I finally made --update work for a couple of units, in one run, another bug popped up: MakeSkel seems to misinterpret the following in TestUnit.pp, most probably at:

   ARecordVar : Record
                  A,B : integer;
                end;

A variable ARecordVar is added to the docs, *and* two variables A and B, which IMO better should become ARecordVar.A and ARecordVar.B. When the unit is updated later, these variables A and B are added to the output again - what made me find this bug. When somebody fixes this bug, will it be possible to also suppress the creation of empty output files? This will simplify the separation of changed units from unchanged ones, where currently all created files have to be inspected for real changes manually :-(

Now I'll try to further extend MkSkel by using FPDoc projects, so that the correct input specifications are used, including all compiler options. Then it will be easy to check the RTL and other packages for updates, and to create the skeletons for all contained units :-)

DoDi

To my knowledge, it should not be necessary ?

When I tried to create the skeletons for all *.pas and *.pp files, I stumbled across exceptions with missing interface sections. It would be nice to prevent such exceptions, when MakeSkel tries to process an program file, whereupon AModule.InterfaceSection is Nil!

makeskel or fpdoc were not designed to be run on programs, so the errors are normal.

Fixed and committed. Rev. 19850.

This is a known problem, which I haven't gotten around to fixing yet. I am currently working on the parser; Hopefully I'll be able to fix this too.

Now I'll try to further extend MkSkel by using FPDoc projects, so that the correct input specifications are used, including all compiler options. Then it will be easy to check the RTL and other packages for updates, and to create the skeletons for all contained units :-)

If you do so, and intend to provide a patch, please keep the patch clean. All your other patches were mostly unusable because of all the 'noise' in them, forcing me to re-implement almost from scratch whatever you did.

Michael.

If you are interested in a --project option for MakeSkel, we should agree about the handling of the project settings. In FPDoc a class TFPDocPackage holds the options, while MakeSkel uses global variables for essentially the same options. Also their options differ: --show-private, --disable-private (keep separate?).

As long as only the Inputs and Descriptions are affected, only MakeSkel.InitOptions and FreeOptions deserve modifications, to use the fields in TFPDocPackage. If you want to update MakeSkel accordingly (option and code to read an project file), I can add the rest.

IMO the --update option of MakeSkel should be handled differently from the normal procedure. At least I find it nasty to have the changes for *all* units of a package in an single XML file (--output), with no indication which units really are affected. But this is fully optional, I implemented the splitted output (into upd.<unit>.xml) in mkskel, the remaining code is not affected.

DoDi

> BTW is it really required to add "-Fi.", so that the parser finds > include files in the current directory (of the unit file)? To my knowledge, it should not be necessary ?

MakeSkel currently complains about missing "dw_htmlchm.inc", when creating the skeletons for the units in fpdoc\.

Such errors are acceptable when a single unit is processed, but it's not nice when a batch of units is stopped before it ends. Such (input) errors should not occur frequently, but cannot be omitted easily when wildcards are used (e.g. --input-dir in fpdoc).

Thanks :-)

Hmm, I didn't intend to supply an patch. I tried, however, to allow for SVN updates without conflicts, and left the original units as unchanged as possible. My "private" changes are enclosed in {$IFDEF DoDi}, which should be easy to find and remove.

Now I created an unfiltered patch, which covers the following:

dglobals.pp:
- Added --common-options=value (compiler options common to all input files).
- Added method TFPDocEngine.OutputLog.
- Catch not assigned(CurModule.InterfaceSection), emit warning.

dw_html.pp:
- Log "Now creating file..." (should occur only when verbose).
- Catch and log error in Element.

fpclasschart, unitdiff: nothing but morphing into unit.

fpdoc.pp: (morph into unit)
- Fix Options.ShowPrivate:=True (was False, what seems not to make sense). Also the property declaration is a bit weird:

   Property ShowPrivate : Boolean Read FHidePrivate Write FHidePrivate;

Should the option read --hide-private?
- Added --common-options.
- Added create auto-project, unless invoked with a project.

fpdocproj.pas:
- Added CommonOptions.

fpdocxmlopts.pas:
- Added CommonOptions.

makeskel.pp: (almost evitable)
- Added Engine.OnLog := @Engine.OutputLog; (enable logging in parser)
- Added OnHandleOption (for non-standard options).

mkfpdoc.pp:
- Catch incomplete imports (package without content file).
- If verbose, log "Creating project" (for use with auto-project).

I can try to enclose above optional changes into $IFDEFs, if you like: CommonOptions
AutoProject
OnHandleOption
VerboseLog
CatchErrors
and include only selected files into the patch.

DoDi