On 10/09/14 14:25, Patrick Goupell wrote:
>
> I am having some trouble with
> mseide-msegui/lib/common/kernel/linux/*.pas units. fpdoc cannot find
> some include files.
It's because Martin hard-coded the path to the include file (which isn't
needed), and because he used a Windows path delimiter, and you are using
a Linux version of fpdoc.
To solve the problem:
1) Remove the hard-coded path to the include files in the units
msesocketintf.pas and msesysintf1.pas
eg:
----------[ msesocketintf.pas ]----------------
...snip...
interface
uses
msesystypes,msesys;
{$i msesocketintf.inc}
implementation
...snip...
-----------------[ end ]-------------------
There is NO need for the IFDEF FPC around the include files. There is
also NO reason to hard-code the path because you already pass in the
include file location via the FPC/fpdoc -Fi command line parameter.
2) At this point it worked perfectly for me.
NOTE: The options= parameter tells fpdoc (and FCL Parser) exactly where
to find units and include files. For example:
<!-- lib/comon/kernel/linux -->
<unit file="../lib/common/kernel/linux/cthreads.pas"
options="-Fu../lib/common/* -Fu../lib/common/kernel/linux
-Fi../lib/common/kernel"/>
The above is exactly from the fpdoc project XML file I posted before. No
changes were needed.
A few suggestions
===================
* DON'T include kernel/linux/* and kernel/windows/* in the fpdoc
documentation. They cover the same thing.
* In fact, DON'T include either kernel/linux/* or kernel/windows/* in
the documentation, because they are back-end code - something a
developer using MSEgui will probably never need to know about.
* Don't include any of the following in the documentation
lib/comon/designutils
lib/comon/fpccompatibility
lib/comon/sysutils
lib/comon/unicode
lib/comon/opengl
lib/common/kernel/mseconsts_*.pas
They simply ain't useful to a developer using MSEgui. Especially in
the beginning of the documentation stage. Maybe if everything else is
documented, include some of those units, but definitely not all of
them.
* Start documenting the base units like mseactions, mseapplication,
mseevent etc. Then working your way up the class hierarchy. Use fpdoc's
ability to inherit documentation from parent classes so you don't have
to duplicate help contents.
* Then move on to the most popular units or widgets next. This means
maximum benefit of available documentation - even though you might
only have documented 10% of MSEgui. eg: I so often see developers
struggle with the Treeview widget in MSEgui - so that will be a
good candidate when you reach this stage.
* Add compilable example code with the documentation. This is
always a huge benefit to developers. I know the Borland Kylix 3
& Delphi 7 documentation was excellent at that.
Regards,
Graeme
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
mseide-msegui-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
