[fpc-devel] Errors with make rtl.chk on Windows

[Hans-Peter Diettrich]

michael.vancanneyt at wisa.be schrieb:

> Speed is also an option. If we start allowing macros, then as an end result
> the macros must be processed in the whole XML file. The documentation 
> XML is rather big; the project file is small.
> 
> In true unix philosophy, I think it is better to have many small and 
> simple tools
> cooperating well than one large tool which tries to do everything and fails
> miserably. There you have, in a nutshell, the design philosophy of fpdoc 
> :-)

I dare to disagree, WRT the Unix philosophy. When I was used to create 
Delphi programs from simple project files, it was hell writing Makefiles 
for the same purpose. And when, according to the Unix philosophy, "make" 
was extended with "automake", "configure" and more bloat, the user has 
to learn a couple of additional languages (5 or so), and has to 
obfuscate the source code with options for all these tools, in order to 
make a project multi-platform. FPC does all that a bit better, using 
only "make" (or fpcmake), and a well designed directory structure :-)

WRT fpdoc itself, it IMO should work with either CLI or GUI, i.e. the 
worker code should be separated from the invocation. This is not 
possible right now, when CreateDocumenation is available only in the CLI 
version :-(

Otherwise it were easy to extend the functionality of fpdoc "from 
outside", by deriving classes and inserting additional passes between 
the collection of (commandline or project) options and the document 
generation. Bummer! I should apply that concept to my own fpdoc 
extensions, by making the fpdoc classes more virtual, and moving my own 
code into derived classes in separate units...

Would a patch be acceptable, that splits some methods into parts (new 
virtual methods), so that more features can be implemented without 
touching the fpdoc base classes further?

DoDi