In our previous episode, Marco van de Voort said:
> Some things in the latex parts were fixed (but there is still a bit of
> shellscript somewhere).
(for the people wondering, it is the for loop in Makefile.4ht)
___
fpc-devel maillist - fpc-devel@lists
In our previous episode, Michael Van Canneyt said:
> > nobody else's ideas count any more from that point on. Core developer
> > has spoken! :-( One has to love the way the FPC team works.
>
> Unfortunately, Graeme, you are mistaken in your facts.
>
> The fpdoc project file support already exist
Michael Van Canneyt schrieb:
I still miss a "required package" option (variation of --import?),
describing the packages whose content files are required to build a
dependent package documentation. Since the location of these packages
can differ on every machine, the user should be alerted when
Michael Van Canneyt schrieb:
All I did now was add some options for its manipulation,
based on the problems Hans was experiencing when he tried to build the
FPC docs.
Right, I'm impressed that almost all of my wishes have been implemented
now. I was quite pessimistic after the first reaction
Michael Van Canneyt schrieb:
Waiting for a commit of these extensions, and for a description of
your mkfpdocproj tool...
Everything was already committed in rev. 19755.
Now it has arrived here, and it really looks great :-)
One comment on ParseOption:
else if s = '--show-private' then
On Sun, 4 Dec 2011, Graeme Geldenhuys wrote:
On 4 December 2011 21:55, Michael Van Canneyt wrote:
doubt it will make it into fpdoc. Core developers always trump mere
contributors like us. ;-)
We simply have a vision and try to remain true to it.
Ideas corresponding to this vision will make
On 4 December 2011 21:55, Michael Van Canneyt wrote:
>> doubt it will make it into fpdoc. Core developers always trump mere
>> contributors like us. ;-)
>
> We simply have a vision and try to remain true to it.
> Ideas corresponding to this vision will make it. Others not.
Hardly any time was gi
On 4 December 2011 21:41, Hans-Peter Diettrich wrote:
> Where are they defined, what's the syntax for their definition and use, how
> are nested macros expanded, why is my macro not found...
You are over exaggerating a bit. Macros are used all over the place
with great success. FPC, Lazarus IDE,
On 4 December 2011 18:11, Marco van de Voort wrote:
>
> Because then you can't have multiple projects using the same content and
> sources in different paths.
I'm afraid I don't understand your point? fpdoc is about documenting
API's. Those are rather specific to a single project. Could you suppl
On Sun, 4 Dec 2011, Graeme Geldenhuys wrote:
This solution has already been rejected by the core developers [no comment
here :-],
Same here. Michael doesn't seem keep to my idea either, so I very much
doubt it will make it into fpdoc. Core developers always trump mere
contributors like us.
On Sun, 4 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
I did several things:
1. Enable various log levels in parser and scanner. It uses an event
handler.
(writing to terminal is not possible)
2. Route all this logging through the TPasContainer.
I tried to remo
Graeme Geldenhuys schrieb:
On 4 December 2011 16:17, Hans-Peter Diettrich wrote:
I thought about such a simplification, too, but you'll get some objections:
I believe I already have. ;-)
How then do you want to document files for different platforms?
(needs to supply different source and in
Michael Van Canneyt schrieb:
I did several things:
1. Enable various log levels in parser and scanner. It uses an event
handler.
(writing to terminal is not possible)
2. Route all this logging through the TPasContainer.
I tried to remove all direct writes from all backends and other
pl
On 4 December 2011 16:17, Hans-Peter Diettrich wrote:
>
> I thought about such a simplification, too, but you'll get some objections:
I believe I already have. ;-)
> How then do you want to document files for different platforms?
> (needs to supply different source and include directories)
Macr
On Sat, 3 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
You remember my -n and -v options?
Absolutely, and I'll gladly accept patches implementing those 2 things in
fpdoc.
If you could separate those out from your other work, that would be much
appreciated. If not, s
In our previous episode, Graeme Geldenhuys said:
> > And the contents in the XML is _NOT_ dependent where exactly those files
> > are, as long as fpdoc can find them.
>
> Exactly my point. fpdoc cannot generate documentation without knowing
> where the the *.xml _and_ *.pas files are.
True.
> So
Graeme Geldenhuys schrieb:
On 3 December 2011 17:26, Marco van de Voort wrote:
And the contents in the XML is _NOT_ dependent where exactly those files
are, as long as fpdoc can find them.
Exactly my point. fpdoc cannot generate documentation without knowing
where the the *.xml _and_ *.pas f
On 3 December 2011 18:42, Michael Van Canneyt wrote:
>
> The former (the documenters) will normally work in Lazdoc or whatever tool
> that supplements the IDE, and the IDE knows where all relevant source files
> are.
Not everybody uses lazdoc! I know I don't. And last time I heard, you
told me yo
On 3 December 2011 17:26, Marco van de Voort wrote:
>
> And the contents in the XML is _NOT_ dependent where exactly those files
> are, as long as fpdoc can find them.
Exactly my point. fpdoc cannot generate documentation without knowing
where the the *.xml _and_ *.pas files are. So currently we
On Sat, 3 Dec 2011, Graeme Geldenhuys wrote:
On 3 December 2011 16:03, wrote:
First, it keeps the actual documentation XML more "clean" in the sense that
it contains only documentation, and not 'organizational instructions'.
The documentation is useless unless you have the associated *.pa
In our previous episode, Graeme Geldenhuys said:
> > First, it keeps the actual documentation XML more "clean" in the sense that
> > it contains only documentation, and not 'organizational instructions'.
>
> The documentation is useless unless you have the associated *.pas
> unit. As you even ment
On 3 December 2011 16:03, wrote:
> First, it keeps the actual documentation XML more "clean" in the sense that
> it contains only documentation, and not 'organizational instructions'.
The documentation is useless unless you have the associated *.pas
unit. As you even mentioned earlier. fpdoc doe
michael.vancann...@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
Tomas Hajny schrieb:
When ever required, the platform or widgetset specific *units* deserve
their own documentation (sources) in the first place. Then it's only a
minor effort to create specialized fpdoc projects, which use the right
units and create the documentation for them. Every user then
Michael Van Canneyt schrieb:
You remember my -n and -v options?
Absolutely, and I'll gladly accept patches implementing those 2 things
in fpdoc.
If you could separate those out from your other work, that would be much
appreciated. If not, send whatever you have, and I'll try to extract it
m
On Sat, 3 Dec 2011, Graeme Geldenhuys wrote:
On 3 December 2011 01:59, Michael Van Canneyt wrote:
Already included: all XML files are discarded, when they don't contribute
to the current package :-)
Because of the loose coupling between XML files and source files, there is
no way to know
In our previous episode, Graeme Geldenhuys said:
> I've always wonder about the very verbose command line parameters used
> with fpdoc. Why couldn't the XML simply mention which unit(s) it
> documents. You could also include macros [eg: $(somemacro) ] which
> fpdoc could substitute when the xml fil
On 3 December 2011 01:59, Michael Van Canneyt wrote:
>> Already included: all XML files are discarded, when they don't contribute
>> to the current package :-)
>
>
> Because of the loose coupling between XML files and source files, there is
> no way to know if a XML file is contributing or not, un
On Sat, 3 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
One objection is for instance that your proposal will cause all XML files
to be loaded both when FCL and RTL documentation are created.
Already included: all XML files are discarded, when they don't contribute
to
On 2 Dec 11, at 20:27, Hans-Peter Diettrich wrote:
> Sven Barth schrieb:
>
> > Out of curiosity: How could/would one create one documentation of source
> > which supports multiple platforms, but where there are identifiers that
> > are only available for some platforms? (like our RTL)
>
> Right
Michael Van Canneyt schrieb:
I split the tool so the class that does the actual work can be
integrated in e.g. a GUI tool for quick manipulation of project files.
I expect and hope the tool will solve most - if not all - of the
problems you experienced as well.
A first note:
A commandline
Michael Van Canneyt schrieb:
One objection is for instance that your proposal will cause all XML
files to be loaded both when FCL and RTL documentation are created.
Already included: all XML files are discarded, when they don't
contribute to the current package :-)
Because of the loose coup
On Fri, 2 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description file specifications can be extended by a platform attribute,
On Fri, 2 Dec 2011, Sven Barth wrote:
On 02.12.2011 19:37, Michael Van Canneyt wrote:
On Fri, 2 Dec 2011, Sven Barth wrote:
Am 02.12.2011 17:21, schrieb Michael Van Canneyt:
This means that we can document platform-specific items in additional
files, which are automatically merged with
Sven Barth schrieb:
Out of curiosity: How could/would one create one documentation of source
which supports multiple platforms, but where there are identifiers that
are only available for some platforms? (like our RTL)
Right, that's a problem - but how many identifiers are really affected?
I
Michael Van Canneyt schrieb:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description file specifications can be extended by a platform
attribute, so that problems arising from multiple (platform sp
On 02.12.2011 19:37, Michael Van Canneyt wrote:
On Fri, 2 Dec 2011, Sven Barth wrote:
Am 02.12.2011 17:21, schrieb Michael Van Canneyt:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description fi
On Fri, 2 Dec 2011, Michael Van Canneyt wrote:
You would be far better off making separate tools that implement these
automatisms. You can write a e.g. tool that creates or updates a project file
based on a directory scan.
I have no problem including such tools in the FPC distribution, wherea
On Fri, 2 Dec 2011, Sven Barth wrote:
Am 02.12.2011 17:21, schrieb Michael Van Canneyt:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description file specifications can be extended by a platform
a
Am 02.12.2011 17:21, schrieb Michael Van Canneyt:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description file specifications can be extended by a platform
attribute, so that problems arising from mu
On Fri, 2 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
If there are any platform-specific identifiers, the docs have always
contained the linux-specific ones.
I'm just about to create a Windows version of the RTL docs. In contrast to
the assumption, that one XML file
On Fri, December 2, 2011 11:18, Marco van de Voort wrote:
> In our previous episode, Tomas Hajny said:
>>
>> Is this the right fix? Shouldn't it be possible to generate docs based
>> on
>> other targets as an option?
>
> What do you expect from that, other then that a few symbols disappear ?
> (tha
On Fri, December 2, 2011 11:27, Michael Van Canneyt wrote:
> On Fri, 2 Dec 2011, Tomas Hajny wrote:
>> On Thu, December 1, 2011 13:27, michael.vancann...@wisa.be wrote:
>>> On Thu, 1 Dec 2011, Marco van de Voort wrote:
.
.
Afaik the docs are hardwired for Linux. Even if you are on host
Michael Van Canneyt schrieb:
If there are any platform-specific identifiers, the docs have always
contained the linux-specific ones.
I'm just about to create a Windows version of the RTL docs. In contrast
to the assumption, that one XML file could hold descriptions of multiple
modules, I tes
Michael Van Canneyt schrieb:
The patch changes nothing to the content of the docs, it just makes sure
that the parser finds all files on Windows.
If there are any platform-specific identifiers, the docs have always
contained the linux-specific ones.
The patch changes nothing about this.
Ri
On Fri, 2 Dec 2011, Tomas Hajny wrote:
On Thu, December 1, 2011 13:27, michael.vancann...@wisa.be wrote:
On Thu, 1 Dec 2011, Marco van de Voort wrote:
In our previous episode, Hans-Peter Diettrich said:
commandline, which are not handled properly by the Windows shell. I
fixed this manually
In our previous episode, Tomas Hajny said:
>
> Is this the right fix? Shouldn't it be possible to generate docs based on
> other targets as an option?
What do you expect from that, other then that a few symbols disappear ? (that
are hopefully already annotated as platform specific?)
On Thu, December 1, 2011 13:27, michael.vancann...@wisa.be wrote:
> On Thu, 1 Dec 2011, Marco van de Voort wrote:
>
>> In our previous episode, Hans-Peter Diettrich said:
>>> commandline, which are not handled properly by the Windows shell. I
>>> fixed this manually, by editing the Makefile.
>>>
>>
michael.vancann...@wisa.be schrieb:
Perhaps linux/sockets.pp should be replaced by win/sockets.pp?
Or should the Makefile supply the Linux/Unix include directories,
instead those of the current platform (Windows)?
The latter. The paths must be appended, but I already committed a fix for
thi
On Thu, 1 Dec 2011, Hans-Peter Diettrich wrote:
See Mantis #20786 for details.
The first problem was the use of single quotes in the generated fpdoc
commandline, which are not handled properly by the Windows shell. I fixed
this manually, by editing the Makefile.
Next I get the following e
On Thu, 1 Dec 2011, Marco van de Voort wrote:
In our previous episode, Hans-Peter Diettrich said:
commandline, which are not handled properly by the Windows shell. I
fixed this manually, by editing the Makefile.
Next I get the following error messages:
Afaik the docs are hardwired for Linu
In our previous episode, Hans-Peter Diettrich said:
> commandline, which are not handled properly by the Windows shell. I
> fixed this manually, by editing the Makefile.
>
> Next I get the following error messages:
Afaik the docs are hardwired for Linux. Even if you are on host windows, you
shou
52 matches
Mail list logo
