Hi,

I'm using a fpdoc project file for fpGUI documentation. The project file idea works much better than a massive set of command line parameters. So kudos to whoever thought of the project file idea.

I just have one question though.... Can the project file manage two or more output formats? It is often the case that one will generate say INF, CHM, HTML etc docs. So how is the project file supposed to be setup for say INF and HTML output?

At the moment I have commented lines which I have to copy and paste depending on the output format.

My workflow goes something like this.

1) I want to generate IPF output. I copy and paste the commented IPF settings in the fpdoc project file and overwrite some active (not commented) lines. eg: the <package> line and some <option> lines.
2) Run fpdoc
3) I want to generate HTML output. I copy and paste the commented HTML settings in the fpdoc project file and overwrite some active (not commented) lines. eg: the <package> line and some <option> lines.
4) Run fpdoc
5).... repeat for whatever formats I want.

Does fpdoc project file (maybe in 2.6.3 or 2.7.1) support multiple options that only relate to specific output formats?

eg:

<options format="ipf">
<option output="fpgui.ipf">
<option name="hide-protected" value="true"/>
<option name="duplinkeddoc" value="true"/>
</options>

<options format="html">
<option output="html/" contentfile="fpgui.cnt">
<option name="hide-protected" value="true"/>
<option name="footer-date" value="yyyy-mm-dd"/>
</options>

<options format="chm">
<option output="fpgui.chm" contentfile="fpgui.cnt"> <option name="hide-protected" value="true"/>
</options>

Maybe the 'output' and 'contentfile' attributes could maybe be part of the <options> tag, instead of the <option> tag.

If this (or something similar) is not currently possible, then I guess I have to continue working as I am now - copy & paste. The alternative, is to have separate project files for each output format, but then you get the issue of having to remember to sync <unit> and <description> lines if any other project files change.

If you are unclear of what I am trying to say or ask, here is my fpdoc project file for fpGUI. Note the commented lines at the top and bottom of the XML file.

https://github.com/graemeg/fpGUI/blob/develop/docs/fpgui-docs-project.xml

Regards,
- Graeme -

Well, I would be to blame for this.

Currently not. I did not think about this. But I suppose it can be added, no problem.

But when I do domething like that, then only the backend options would be allowed to differ. I see no need to put all options in backend-specific option sets: the input files etc. should not differ per back-end.

A simpler solution could also be the support for an include of a separate file. Then you could put common things (list of files) in one file, and create top-level files per format you want to produce.

Michael.

Michael Van Canneyt wrote

Well, I would be to blame for this.

:-)

But when I do domething like that, then only the backend options would be allowed to differ. I see no need to put all options in backend-specific option sets: the input files etc. should not differ per back-end.

Correct, and that is what I had in mind too. The <unit> and <description> parts are common to all output formats.

As the XML snippet from my previous email shows…

1) The <options> node will probably need to change by adding a format attribute. That way we can have “options” per output format.

2) The <package> node will need to change, or at least some attributes will have to move to a different location in the XML. Currently there is only one “output” attribute value. The problem with that is that value changes for different output formats. For example: IPF and CHM specifies a file with different extension, HTML specifies a directory path etc.

A simpler solution could also be the support for an include of a separate file. Then you could put common things (list of files) in one file, and create top-level files per format you want to produce.

I would prefer a single xml project file if you don't mind. It will be much easier to manage and edit.

Regards,
- Graeme -

In our previous episode, Michael Van Canneyt said:

A simpler solution could also be the support for an include of a separate file. Then you could put common things (list of files) in one file, and create top-level files per format you want to produce.

I think that is better. Nearly all options have some special params (like --auto-toc --auto-index --make-searchable etc)

These are already supported.

Everything not recognized as 'global' is added to backendoptions, a stringlist. This stringlist is fed to the backend.

Michael.

In our previous episode, Michael Van Canneyt said:

I meant one project-file-that-$includes-base-filesetup, so that you can have one project per backend without duplicating the main file related settings.

Or can you have multiple backend options for different backends per project already?

No.

But we're talking about the same thing. So, include file will solve many of these things.

Michael.

I will check how to best adapt the format.

Problem is then that the format must be set first. The nodes are scanned sequentially...

No reason not to have both...

Michael.

In our previous episode, Michael Van Canneyt said:

I was merely expressing support for that option yes. Or at least a solution that keep differing backend options in mind.