[fpc-devel] Errors with make rtl.chk on Windows
DrDiettrich1 at aol.com
Sat Dec 3 16:14:18 CET 2011
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
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?
More information about the fpc-devel