Currently fpdoc stores many options in the project files, but this can cause problems. Once a boolean option is stored as True, e.g. <option name="hide-protected" value="true"/>
it cannot be turned off by a different commandline option :-(

This raises the question, which options should be stored in project files at all, or how the stored options can be overridden by commandline options. The simplest solution would be another commandline option --ignore-project-options (much shorter, if possible), that forces to ignore at least all boolean options read from a project file.

DoDi

Hans-Peter Diettrich wrote

Currently fpdoc stores many options in the project files, but this can cause problems. Once a boolean option is stored as True, e.g.  <option name="hide-protected" value="true"/> it cannot be turned off by a different commandline option :-(

I know this might sound silly, but simply edit the project options file?? Wasn't that the whole point of the "lets implement a project file for fpdoc"?

Or copy the existing project option file, change the setting in that copy, then tell fpdoc to use that second copy when it generates docs. Have multiple project files and use one when needed. Please, lets not add more and more command line options... we might just hit the Windows limit again! ;-)

I thought this was the whole point for wanting project files. Have multiple project files, and reduce command line parameters. Please correct me if I am wrong - maybe I misunderstood the reasoning for project files.

When we want to distribute fpdoc project files instead of scripts, a user should not have to edit these files - after every SVN update :-(

It should be sufficient to specify preferences on the fpdoc commandline, which then should override whatever value was stored in the project file. This works for options with arguments, but not for options without arguments.

DoDi

You can just remove the <option> tags from the project file, or manipulate the options with the tool I made earlier.

Michael.

Hans-Peter Diettrich wrote

When we want to distribute fpdoc project files instead of scripts, a user should not have to edit these files - after every SVN update :-(

They wouldn't have do it every time after a SVN update. SVN (the last time I checked) does not overwrite all local changes during an update. If there is a conflict (same line of code changed local and remotely), then only will it prompt with a resolution choice: use remote setting or keep local setting.

In our previous episode, Graeme Geldenhuys said:

Still it would be the first mandatory edit before making a snapshot. The rest can all be done by just checking out anywhere, and passing some vars to make.

Hans-Peter Diettrich wrote

When we want to distribute fpdoc project files instead of scripts, a user should not have to edit these files - after every SVN update :-(

Can't you select the project file(s) using a command line option ?

-Michael

You can just remove the <option> tags from the project file, or manipulate the options with the tool I made earlier.

Still waiting for a description of your tool.

BTW, I couldn't find Imports used in building the documentation any more. Did I miss something?

DoDi

BTW, I couldn't find Imports used in building the documentation any more. Did I miss something?

Sorry, the reference was not found because mkfpdoc is missing from the fpdoc project files - please add it.

DoDi

Patience.
I have only 2 hands and I have a day-time job to be able to pay for my daily food.

BTW, I couldn't find Imports used in building the documentation any more. Did I miss something?

I forgot to add save/load of imports to the project file. I fixed that.

Michael.

To my knowledge, confirmed by SVN, it is in the .lpi project file ?

Michael.