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 20:40, Hans-Peter Diettrich wrote:
>
> When we want to distribute fpdoc project files instead of scripts, a user
> should not have to edit these files - after every SVN update :-(
They wouldn't have do it every time after a SVN update. SVN (the last
time I checked) does not ove
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, Hans-Peter Diettrich wrote:
Currently fpdoc stores many options in the project files, but this can cause
problems. Once a boolean option is stored as True, e.g.
it cannot be turned off by a different commandline option :-(
This raises the question, which options should
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
Graeme Geldenhuys schrieb:
On 4 December 2011 20:09, Hans-Peter Diettrich wrote:
Currently fpdoc stores many options in the project files, but this can cause
problems. Once a boolean option is stored as True, e.g.
it cannot be turned off by a different commandline option :-(
I know this mig
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
On 4 December 2011 20:09, Hans-Peter Diettrich wrote:
> Currently fpdoc stores many options in the project files, but this can cause
> problems. Once a boolean option is stored as True, e.g.
>
> it cannot be turned off by a different commandline option :-(
I know this might sound silly, but sim
Currently fpdoc stores many options in the project files, but this can
cause problems. Once a boolean option is stored as True, e.g.
it cannot be turned off by a different commandline option :-(
This raises the question, which options should be stored in project
files at all, or how the stor
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
22 matches
Mail list logo
