Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2012-02

FPDocManager now handles selectable FCL packages

15 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Hans-Peter Diettrich

Only few FCL units are documented right now. This is not a special limitation for Lazarus applications, which do not normally use FCL units. But when e.g. the PParser unit is used in a project (like FPDocManager), a few notes on the essenial parts of selected units are appreciated. That's why the (now removed) docs/xml/fcl directory had been added for such inofficial descriptions. For now we assume that such a directory exists, and has been added to the FCL options in FPDocManager.

The FPDoc Editor can be used in the IDE, to add descriptions even to FCL units. But when somebody wants to supply such descriptions for addition to the official docs, some problems become noticeable.

Most FPDoc tools fail to work on units which deserve special compiler options, when the user cannot supply the required options. I.e. you may not be able to add descriptions in the FPDoc Editor, or MakeSkel or LazDE creates only an empty or invalid skeleton. In these (rare) cases you are most probably lost :-(

This was the reason for the addition of *selectable* FCL packages, for which the FPDocManager now can create documentation skeletons, and allows to update, syntax check, and to create the final documentation for the contained units.

Before you start documenting new FCL units, you should check the according package in the FCL packages list, and then try to Refresh the FCL docs. This may fail, e.g. for fcl-process, due to beformentioned missing compiler options. Then you'll have to uncheck that package again, and stop working on it for now[1].

Otherwise you'll get the skeletons for all units, pertaining to that package, *and* which had not been documented before by e.g. using the FPDoc Editor. As soon as a description file is found, the Refresh feature only will create *update* files, which have to be merged manually into the existing file. Or, even worse, MakeSkel may extinguish your previous work (untested). An automatic merge is on my ToDo list, but don't hold your breath. So you better create skeletons *before* adding any documentation to yet undocumented units.

Please note that your added descriptions do *not* become part of the entire FCL package, i.e. they are not listed in the FCL units pane. Nonetheless they are checked or added to the final docs by the FPDocManager, when no specific unit is selected.

The remainder is for keen users, which want to work around beforementioned problems.

[1] The FPDocManager creates both an INI file and an FPDoc project for all registered packages. In the case of the FCL package it also creates an additional fcl_prj_ext.xml project file, which contains all the added source and description files. This file is re-created for every operation on the FCL package, based on an scan of the FCL source and description directories. This way the input files are supplied for all added description files, no need to add them explicitly.

The project files can be edited manually and supplied to FPDoc or MakeSkel. This way a user can e.g. try to figure out the compiler options, required to process specific units properly.

So much for now.

DoDi

Reply by email

Mattias Gaertner
to Hans-Peter Diettrich
[...] Most FPDoc tools fail to work on units which deserve special compiler options, when the user cannot supply the required options. I.e. you may not be able to add descriptions in the FPDoc Editor,

Please report FCL units that fail to parse in Lazarus.

Mattias

Reply by email

Hans-Peter Diettrich
to Mattias Gaertner
Show quoted text 9 lines
On Fri, 17 Feb 2012 14:30:17 +0100 Hans-Peter Diettrich wrote: > [...] > Most FPDoc tools fail to work on units which deserve special compiler > options, when the user cannot supply the required options. I.e. you may > not be able to add descriptions in the FPDoc Editor, Please report FCL units that fail to parse in Lazarus.

I didn't talk about Lazarus (IDE)?

But here is such a Lazarus unit:
D:\repos\lazarusTrunk\components\jcf2\Parse\Tokens.pas IMO this is a different issue, when the unit is not part of the project or of a loaded package.

DoDi

Reply by email

Mattias Gaertner
to Hans-Peter Diettrich
Show quoted text 12 lines
Mattias Gaertner schrieb: > On Fri, 17 Feb 2012 14:30:17 +0100 > Hans-Peter Diettrich wrote: > >> [...] >> Most FPDoc tools fail to work on units which deserve special compiler >> options, when the user cannot supply the required options. I.e. you may >> not be able to add descriptions in the FPDoc Editor, > > Please report FCL units that fail to parse in Lazarus. I didn't talk about Lazarus (IDE)?

Ok, sorry. I thought you talked about the "FPDoc Editor" of the IDE.

Mattias

Reply by email

Mattias Gaertner
to Hans-Peter Diettrich: I didn't talk about Lazarus (IDE)? But here is such a Lazarus unit:…
Show quoted text 15 lines
Mattias Gaertner schrieb: > On Fri, 17 Feb 2012 14:30:17 +0100 > Hans-Peter Diettrich wrote: > >> [...] >> Most FPDoc tools fail to work on units which deserve special compiler >> options, when the user cannot supply the required options. I.e. you may >> not be able to add descriptions in the FPDoc Editor, > > Please report FCL units that fail to parse in Lazarus. I didn't talk about Lazarus (IDE)? But here is such a Lazarus unit: D:\repos\lazarusTrunk\components\jcf2\Parse\Tokens.pas

I found a project jcf.lpi which uses this unit.
I fixed compilation.
No parser error.

What project/package have you used?

IMO this is a different issue, when the unit is not part of the project or of a loaded package.

What do you expect?

Mattias

Reply by email

Hans-Peter Diettrich
to Mattias Gaertner
Show quoted text 13 lines
On Fri, 17 Feb 2012 19:09:54 +0100 Hans-Peter Diettrich wrote: > Mattias Gaertner schrieb: >> On Fri, 17 Feb 2012 14:30:17 +0100 >> Hans-Peter Diettrich wrote: >> >>> [...] >>> Most FPDoc tools fail to work on units which deserve special compiler >>> options, when the user cannot supply the required options. I.e. you may >>> not be able to add descriptions in the FPDoc Editor, >> Please report FCL units that fail to parse in Lazarus. > I didn't talk about Lazarus (IDE)?

Clarification: When working on/with the FPDocManager, or with the documentation commandline tools (fpdoc, makeskel...), the fpdoc units can report errors when processing units. This is one scenario. When I open these reported units in the IDE, these are not normally part of the current project, so this is another scenario.

The file fcl-process/src/pipesipc.pp is broken on many platforms. It only contains:

   {$define ipcunit}
   {$i simpleipc.inc}

but neither dummy/simpleipc.inc nor win/simpleipc.inc care about ipcunit, so that the module lacks unit, interface, implementation clauses and an "end.". This is invalid syntax. When included by simpleipc.pp, the module syntax for "unit simpleipc;" is okay, beforementioned parts reside in simpleipc.pp.

Even if pipesipc.pp were a program, a "begin ... end." part is missing, and it's known that fpdoc doesn't accept program modules.

These are definitely bugs in the fcl-process sources, should I file an bug report?

Show quoted text 6 lines
> But here is such a Lazarus unit: > D:\repos\lazarusTrunk\components\jcf2\Parse\Tokens.pas I found a project jcf.lpi which uses this unit. I fixed compilation. No parser error.

I just can't test your update, due to SVN server problems. In the last version the CodeExplorer didn't show any entries for this unit.

What project/package have you used?

No special package. I only opened the unit in the IDE, from the global search results for "parser".

> IMO this is a different issue, when the unit is not part of the project > or of a loaded package. What do you expect?

I don't expect that the IDE (code tools...) can handle units out of their containing package, when these require special compiler options (include paths...). FPDoc Editor alerts the user on an attempt to document an unit, which is not part of the current project or of a (loaded) package.

Please note that the Lazarus FCL package only contains an subset of the FPC FCL units, including simpleipc.pp, but not pipesipc.pp. Can I assume that all FCL units, which require special compiler options, should become part of the Lazarus FCL package? In this case the various simpleipc.inc files have to be fixed, before pipesipc.pp can be added to this package. But even then I don't understand how the required include path for simpleipc.pp is found by Lazarus.

DoDi

Reply by email

Mattias Gaertner
to Hans-Peter Diettrich
Show quoted text 10 lines
[...] >> But here is such a Lazarus unit: >> D:\repos\lazarusTrunk\components\jcf2\Parse\Tokens.pas > > I found a project jcf.lpi which uses this unit. > I fixed compilation. > No parser error. I just can't test your update, due to SVN server problems. In the last version the CodeExplorer didn't show any entries for this unit.

The unit needs an include file, that is in another directory. Open the jcf.lpi, so that the IDE knows where to find it. Eventually the code explorer can ignore missing include files.

[...] Can I assume that all FCL units, which require special compiler options, should become part of the Lazarus FCL package?

No.

In this case the various simpleipc.inc files have to be fixed, before pipesipc.pp can be added to this package. But even then I don't understand how the required include path for simpleipc.pp is found by Lazarus.

The FPC sources are special. The IDE defines some paths for them. See Tools / Codetools defines editor.

Mattias

Reply by email

Michael Van Canneyt
to Hans-Peter Diettrich: Clarification: When working on/with the FPDocManager, or with the documentation…
Hans-Peter Diettrich wrote 30 lines
Mattias Gaertner schrieb: > On Fri, 17 Feb 2012 19:09:54 +0100 > Hans-Peter Diettrich wrote: > >> Mattias Gaertner schrieb: >>> On Fri, 17 Feb 2012 14:30:17 +0100 >>> Hans-Peter Diettrich wrote: >>> >>>> [...] >>>> Most FPDoc tools fail to work on units which deserve special compiler >>>> options, when the user cannot supply the required options. I.e. you may >>>> not be able to add descriptions in the FPDoc Editor, >>> Please report FCL units that fail to parse in Lazarus. >> I didn't talk about Lazarus (IDE)? Clarification: When working on/with the FPDocManager, or with the documentation commandline tools (fpdoc, makeskel...), the fpdoc units can report errors when processing units. This is one scenario. When I open these reported units in the IDE, these are not normally part of the current project, so this is another scenario. The file fcl-process/src/pipesipc.pp is broken on many platforms. It only contains: {$define ipcunit} {$i simpleipc.inc} but neither dummy/simpleipc.inc nor win/simpleipc.inc care about ipcunit, so that the module lacks unit, interface, implementation clauses and an "end.". This is invalid syntax. When included by simpleipc.pp, the module syntax for "unit simpleipc;" is okay, beforementioned parts reside in simpleipc.pp.

That's how it is meant to be.

Show quoted text 6 lines
Even if pipesipc.pp were a program, a "begin ... end." part is missing, and it's known that fpdoc doesn't accept program modules. These are definitely bugs in the fcl-process sources, should I file an bug report?

No. Unit pipesipc only works on Unixes.

It's simply not supported on other platforms; if you try any of these platforms, obviously it wil not work.

If you check fpmake.pp or the Makefile.fpc.fpcmake, you'll see that this unit is not compiled for non-unix platforms:

[target]
units=pipes process
units_beos=simpleipc dbugmsg dbugintf pipesipc
units_haiku=simpleipc dbugmsg dbugintf pipesipc
units_freebsd=simpleipc dbugmsg dbugintf pipesipc
units_darwin=simpleipc dbugmsg dbugintf pipesipc
units_iphonesim=simpleipc dbugmsg dbugintf pipesipc units_solaris=simpleipc dbugmsg dbugintf pipesipc
units_netbsd=simpleipc dbugmsg dbugintf pipesipc
units_openbsd=simpleipc dbugmsg dbugintf pipesipc
units_linux=simpleipc dbugmsg dbugintf pipesipc
units_win32=simpleipc dbugmsg dbugintf
units_win64=simpleipc dbugmsg dbugintf
units_wince=simpleipc dbugmsg dbugintf
units_qnx=simpleipc dbugmsg dbugintf pipesipc
units_os2=simpleipc dbugmsg dbugintf
units_emx=simpleipc dbugmsg dbugintf

This is one of the reasons why I think the 'include all files' option in fpdoc is a bad idea. It just does not work for scenarios where not all units will work on all platforms. If someone just happens to be on the 'wrong' platform, and consequently runs into problems, he is guided into thinking that there is an error in the sources. There is no error, the person is just trying to do something which is not supported, and which is not meant to be supported.
But because of the 'automatisms' he runs into trouble...

I prefer to avoid this and force people to think about what they are doing.

Michael.

Reply by email

Hans-Peter Diettrich
to Mattias Gaertner: On Sat, 18 Feb 2012 05:33:15 +0100 The unit needs an include file, that is in another…
The unit needs an include file, that is in another directory.

This is the typical reason for parser errors.

Open the jcf.lpi, so that the IDE knows where to find it.

I didn't want to do anything with this unit, I mentioned it only because you asked for examples.

Eventually the code explorer can ignore missing include files.

Missing includes in the implementation section do not really affect the code explorer.

The FPC sources are special. The IDE defines some paths for them. See Tools / Codetools defines editor.

Hm, I have no idea what those entries mean:
$(#IncPath);$PkgIncPath(FCL 1.0.1)
But since I'm not responsible, I do not have to know ;-)

DoDi

Reply by email

Hans-Peter Diettrich
to Michael Van Canneyt: That's how it is meant to be. No. Unit pipesipc only works on Unixes. It's simply not…
Show quoted text 7 lines
> These are definitely bugs in the fcl-process sources, should I file an > bug report? No. Unit pipesipc only works on Unixes. It's simply not supported on other platforms; if you try any of these platforms, obviously it wil not work.

[...]

The "make" stuff is not normally helpful to me :-(

This is one of the reasons why I think the 'include all files' option in fpdoc is a bad idea. It just does not work for scenarios where not all units will work on all platforms.

The RTL docs already include many units which are not usable under Windows. Such documentation may be useful when cross-compiling, not an argument for ommission from certain platform docs.

Show quoted text 6 lines
If someone just happens to be on the 'wrong' platform, and consequently runs into problems, he is guided into thinking that there is an error in the sources. There is no error, the person is just trying to do something which is not supported, and which is not meant to be supported. But because of the 'automatisms' he runs into trouble...

A comment in such units could help: "This unit is usable on Linux only", perhaps as a conditional error. This would help the documentation author in figuring out the right include directories, and other unit users will learn *why* the unit doesn't compile on their platform.

I prefer to avoid this and force people to think about what they are doing.

I'm thinking much about what I'm doing, but my conclusions often differ from those of other people ;-)

DoDi

Reply by email

Mattias Gaertner
to Hans-Peter Diettrich: This is the typical reason for parser errors. I didn't want to do anything with this…
Show quoted text 15 lines
Mattias Gaertner schrieb: > The unit needs an include file, that is in another directory. This is the typical reason for parser errors. > Open the jcf.lpi, so that the IDE knows where to find it. I didn't want to do anything with this unit, I mentioned it only because you asked for examples. > Eventually the code explorer can ignore missing include files. Missing includes in the implementation section do not really affect the code explorer.

The Tokens.pas include file is in front of the interface.

Show quoted text 6 lines
> The FPC sources are special. The IDE defines some paths for > them. See Tools / Codetools defines editor. Hm, I have no idea what those entries mean: $(#IncPath);$PkgIncPath(FCL 1.0.1) But since I'm not responsible, I do not have to know ;-)

That is for the Lazarus package FCL.
The defines for fpc sources are under "Free Pascal sources".

Mattias

Reply by email

Hans-Peter Diettrich
to Mattias Gaertner
Show quoted text 8 lines
>> The FPC sources are special. The IDE defines some paths for >> them. See Tools / Codetools defines editor. > Hm, I have no idea what those entries mean: > $(#IncPath);$PkgIncPath(FCL 1.0.1) > But since I'm not responsible, I do not have to know ;-) That is for the Lazarus package FCL. The defines for fpc sources are under "Free Pascal sources".

Thanks, these look a bit more understandable :-)

DoDi

Reply by email

Sven Barth
to Marco van de Voort
Marco van de Voort wrote 7 lines
On Sat, Feb 18, 2012 at 11:58:52AM +0100, Hans-Peter Diettrich wrote: > A comment in such units could help: "This unit is usable on Linux only", Linux Is Not UniX But I don't see the need for comments when the various FPC package formats (Makefile.fpc, fpmake.pp) clearly annotate this.

Especially since the fpmake.pp files consist of rather simple Pascal code ;)

Regards,
Sven

Reply by email

Hans-Peter Diettrich
to Marco van de Voort: Linux Is Not UniX But I don't see the need for comments when the various FPC package…
On Sat, Feb 18, 2012 at 11:58:52AM +0100, Hans-Peter Diettrich wrote: > A comment in such units could help: "This unit is usable on Linux only", Linux Is Not UniX

You know what I meant ;-)

But I don't see the need for comments when the various FPC package formats (Makefile.fpc, fpmake.pp) clearly annotate this. People that refuse to use that, are on their own.

A comment in the files also could be used by the documentation tools, to exclude files for deselected platforms.

IMO it's very bad practice when files contain invalid syntax.

DoDi

Reply by email