Hi,

I was playing around this morning with my console app that can generate a script/batch file to generate documentation for fpGUI.

The content of the script file is every verbose because of the large set of search path options inside each --input="..." parameter.

I'm not sure how the Makefiles in the FPC_Docs repository generates fpdoc parameters, but I found that I only need to specify the search paths in the first --input parameter. For all other documentation units, I only need to specify the source *.pas unit in the --input parameter. FPDoc has cached the previous search paths already, so it can find consecutive input file without problems. This greatly reduces the number of characters passed in the command line to fpdoc.

eg:

Before...

--input="-Fi../src -Fu../src/corelib/x11/ -Fi../src/corelib/x11/ -Fu../src/gui/ -Fu../src/corelib/ ../src/gui/fpg_colorwheel.pas" --descr=xml/gui/fpg_colorwheel.xml \
--input="-Fi../src -Fu../src/corelib/x11/ -Fi../src/corelib/x11/ -Fu../src/gui/ -Fu../src/corelib/ ../src/gui/fpg_colormapping.pas" --descr=xml/gui/fpg_colormapping.xml \
--input="-Fi../src -Fu../src/corelib/x11/ -Fi../src/corelib/x11/ -Fu../src/gui/ -Fu../src/corelib/ ../src/gui/fpg_edit.pas" --descr=xml/gui/fpg_edit.xml \
--input="-Fi../src -Fu../src/corelib/x11/ -Fi../src/corelib/x11/ -Fu../src/gui/ -Fu../src/corelib/ ../src/gui/fpg_tree.pas" --descr=xml/gui/fpg_tree.xml \
...

After....

--input="-Fi../src -Fu../src/corelib/x11/ -Fi../src/corelib/x11/ -Fu../src/gui/ -Fu../src/corelib/ ../src/gui/fpg_colorwheel.pas" --descr=xml/gui/fpg_colorwheel.xml \
--input="../src/gui/fpg_colormapping.pas"
--descr=xml/gui/fpg_colormapping.xml \
--input="../src/gui/fpg_edit.pas" --descr=xml/gui/fpg_edit.xml \ --input="../src/gui/fpg_tree.pas" --descr=xml/gui/fpg_tree.xml \ ...

The final help output is identical in each case.

So if the Makefiles don't do this already, maybe they should. That might be enough to solve the command line limit under Windows? Delaying the pressing need for a project file (though I think this is still the best solution).

Alternatively... Why can't we use introduce a new --searchpath parameter to fpdoc. That parameter contains, you guessed it, the search path to all documentation units. Then --input parameter is simply used to specify the source *.pas unit, nothing more. Pretty much like my second example above.

I'm not sure how the Makefiles in the FPC_Docs repository generates fpdoc parameters, but I found that I only need to specify the search paths in the first --input parameter.

This doesn't look correct to me, at least not for the trunk fpdoc and the RTL documentation.

I was already thinking about package options, which are applied to all input files, e.g.
<units options="-Fi..." linux="-Fi...", win="..."> where 'options' apply to all units, while the optional platform specific options are selected by e.g. --ostarget.

But unit specific options may still be required, no need to change the current commandline support. It may be desireable, however, to allow for commandline *overrides* of the project options.

BTW, I already added the following debug options to my improved fpdoc: -n for a dry run, not creating output files,
-v for verbose messages, useful to find missing includes and bad links.

A project file is created for every invocation of fpdoc. It can be renamed or moved to a safe place, for updates and later use. I found it very useful in fixing script flaws, instead of editing the Makefile. Another use were e.g. the creation of extended or shrunk documentation, by adding --show-private or --hide_protected to the commandline.

DoDi