In my current tests I found empty classes (no members listed), e.g. Classes.TFPList. The Declaration shows:

   Source position: classesh.inc line 170
   type TFPList = class end;

This line reads in the source code as

   TFPList = class;

with the declaration following in line 188 ff.
TFPList = class(TObject)
...

What's wrong?

DoDi

Hm. It should work correctly; At least, it did so in the past. I will need to check this.

Michael.

Hm. It should work correctly; At least, it did so in the past. I will need to check this.

The platform also seems to be involved. When I changed the win32\classes.pp into unix\classes.pp, many classes disappear entirely from the docs (TFileStream, TStrings, TList...).

I'll do some more checks, together with my attempt to collect all HTML docs in one place. Here's my plan:

\MyDocs for all FPC/Lazarus documentation, shall contain the content files (later, for easy references).
\MyDocs\rtl etc. contain the package documentations

DoDi

Wait, did you try this on FPC trunk sources ? That won't work. 2.6.0 sources should be OK.

Trunk contains nested types in the class definitions, and fpdoc cannot handle that. I am currently working on that, though.

Michael.

Wait, did you try this on FPC trunk sources ? That won't work. 2.6.0 sources should be OK.

Ah!

Does there exist a chance (trick) to use the input files of a different installation, without copying the description files?

I'll try --descr-dir, because --input-dir is likely inapplicable to the RTL, due to the many required options.

Or should I simply move the fpcdocs folder into the other installation?

DoDi

Wait, did you try this on FPC trunk sources ? That won't work. 2.6.0 sources should be OK.

I could build RTL and FCL docs from 2.4.2 without major problems (the trunk Makefile was not fully compatible with the old directory structure).

But when I tried to build the LCL, fpdoc crashes badly in THTMLWriter.AppendProcType (SIGSEGV). I tried to catch this error by try-except, but then Windows kills fpdoc. Running from the commandline at least reveals the Element as "FontEnumProc".
I'll have to research a bit more...

The -v option should become more verbose, just for hunting such bugs. And the messages should go to stdout instead of stderr, at least on Windows (with poor redirection capabilities).

DoDi

Hans-Peter Diettrich wrote

Does there exist a chance (trick) to use the input files of a different installation, without copying the description files?

If you use the make command to generate the docs, simply pass the FPCSRCDIR command line parameter.

eg: make rtl.chk fcl.chk FPCSRCDIR=/opt/fpc_2.4.5/src/

In our previous episode, Hans-Peter Diettrich said:

That's a known issue. IIRC a workaround was to compile fpdoc without optimization.

I think the latter is the best.

Michael.

That's correct, but AFAIK, he uses a private description file.

Michael.

StdErr redirection works in Windows the same as on Unix systems.

c:\>someapp.exe > stdout.txt 2> stderr.txt

Will result in the output being split into the two textfiles. You can also redirect only the StdErr.

See also: http://technet.microsoft.com/en-us/library/bb490982.aspx

Regards,
Sven

In our previous episode, Sven Barth said:

Or
someapp.exe 2>&1 > stdoutandstderr.txt

to combine it, but then someapp must flush every line.

Right. I didn't test what fpdoc stores in the new project file when invoked with such a commandline, and whether it could be substituted by --input-dir (most probably not).

Since the document sources reside in their own repository, I simply move around that directory on my system, for now.

Currently the following steps are required to build the project file and the docs:
1. make <whatever> -n > mydocs.bat
2. edit mydocs.bat to make fpdoc create an project file
3. mydocs.bat
4. edit the mydocs.xml project as required
5. fpdoc mydocs.xml

2+3 could be omitted, when fpdoc would automatically create a project. 4+5 can be repeated as often as required.

DoDi

Thanks, I need just that latter case.

But it was much easier to patch fpdoc to use stdout for all messages :-) Now I have to check where and how to show more helpful information.

DoDi

Or if the documentation is created from projectfile directly, which is the plan.

Michael.

Sorry, that didn't help :-(

Perhaps something else is broken, I get an AV just at program start, since I use the trunk compiler. I tried to use an older compiler, too, but that fails due to recent changes to the parser.

DoDi

In our previous episode, Hans-Peter Diettrich said:

So what was your commandline to build the checkout ?

I wonder how such a project file will look like. Currently the Makefile does some configuration, what will not be possible with a common project file.

Can somebody provide an project file, as used to build the official documentation - on a Linux system, I suppose? Then we can find out what may (or may not) be required to run that project on other platforms.

Let me also repeat my thoughts about a general (HTML) documentation layout:
- Keep all documentation in a user specified directory (where the user has all rights), with subdirectories for each package.
- Have one css file in that directory, for use by all HTML pages.
- Put all content files in that directory, too.
- Add a global documentation page, covering all documented packages.

DoDi

Argh, I did updates regularly, but forgot to rebuild the compiler etc. :-(

But rebuilding only removed the AV at program start, fpdoc still crashes at the same location :-(

Fpdoc seems not to collect properly the declarations, e.g. Warning: Target ID of <link> is unknown: "#lcl.Controls.TCursor" should not occur. Now I'll start to check and fix the warnings in the RTL and FCL, perhaps this will give some more insight...

DoDi