doxygen-develop — List for discussing new features, submitting patches, etc.

[Doxygen-develop] Croatian translation update

[Boris B. <bor...@so...>]

Here it is
---

Boris

[Doxygen-develop] re: doxygen-dev-20030824

[Edmund G. <ed...@gr...>]

re: problems with "using" and resolving typedefs and classes
> The new release I just committed to CVS should resolve the above problems.
> Please verify this and let me know of any other problems.

   It (20030824 from CVS) seems to work O.K on linkifying the annotated 
source code for my new test-case (attached), with options:
EXTRACT_ALL            = YES
EXTRACT_PRIVATE        = YES
EXTRACT_STATIC         = YES
SOURCE_BROWSER         = YES
GENERATE_LATEX         = NO

   However there are still a few quirks elsewhere:

1) in "classTest1_1_1Test1Class.html", the parameter types for 
"Test1Class::testGlobalUsingNamespace" and
"Test1Class::testGlobalUsingType" are not hyperlinked (even though they 
are in "namespaceResolveProblem2_8cpp-source.html")

2) Each class and typdef used to have a "referenced by" lists with their 
detailed documentation - this seems to have disappeared.

   The only other possible problem, which may be more of a feature 
rather than a bug is:
3) because typedefs are linked back to the root class which they refer 
to (which is probably what users want most of the time), typedefs to 
system/STL classes are not hyperlinked (line 102 of the annotated 
source) - I assume that I can work around this by forward declaring and 
documenting the relevant STL classes if needed.

Edmund Green.
Greenius Ltd.
http://www.greenius.ltd.uk/

[Doxygen-develop] Documenting the API subset of a project

[Simon G. <sim...@at...>]

Milan wrote:
> I would like to have a new configuration parameter in which I would mention
> the main header file. The generated documentation would contain only
> constructs from the main header file and all the files transitively
> #include-d from it. Other files in the input file set would be left out from
> generated documentation.

It sounds as if you want to generate two sorts of documentation (or you would
never doxygenate and include the 'Other files in the input file set'. One set is
for internal use, and uses the full 'input file set'. The other documentation is
for the library API and refers only to a subset of those files: 'from the main
header file' and the files that includes. Please correct me if I've misunderstood.

At first sight it appears that your requirement will be met by having two
doxyconfig files, one (for the API) being a subset of the other by virtue of
not including  'Other files in the input file set'. The other includes the full
set and generates your unexpurgated internal documentation.

> Let's discuss the feature: should I (or anyone else) implement it? Or can I
> solve it in another way (without having to somehow edit all the files in
> directory).

As long as you keep the doxyconfig file for the public subset of the files
that you want mentioned in the documentation up to date, you should not
need to edit the sources themselves - and we'd be spared another option
in what is already a bewildering array. You can also specify different title
pages, contact information, style sheets etc for the internal and external
documentation easily this way.

Subdirectory organisation (selecting groups of files by location) or a simple
merge script can minimise the overhead of keeping the config files congruent.

I hope this helps

Simon
Technology Programmer, ATD

-- 
Simon Goodwin <sim...@at...>

[Doxygen-develop] Re: A wish: show only files included from a given start file

[Fabian C. <Cen...@in...>]

>I would like to have a new configuration parameter in which I would mention
>the main header file. The generated documentation would contain only
>constructs from the main header file and all the files transitively
>#include-d from it. Other files in the input file set would be left out from
>generated documentation.
>
>Let's discuss the feature: should I (or anyone else) implement it? Or can I
>solve it in another way (without having to somehow edit all the files in
>directory).

I understand that you don't want to edit all the files. But it's already
possible to achieve this if you're willing to. You can #ifdef various sections
of the code and then switch on or off these sections in the config of
doxygen. Like that you can build developer docs, user docs, API docs...
It may already be enough if you #ifdef the #includes of other files. Or
if you just feed the needed files to doxygen and not all of them.

bye  Fabi

[Doxygen-develop] XML Source Listing

[<Nas...@Sy...>]

The creation of source code listing in XML output should be optional, as 
it is somewhat verbose. A lot of processing time will be saved as a result 
of this. A colleague of mine is working on a patch for the latest release 
to fulfil this.

I just wanted to know any comments on this.
______________________________________
Nasser Saleem Ahmed
Software Engineer

Symbian Ltd 
http://www.symbian.com
______________________________________


**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify pos...@sy... and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************

[Doxygen-develop] A wish: show only files included from a given start file

[Milan <mil...@se...>]

Hello,

I would like to suggest a new feature, I haven't find any discussion in the
list's archives about this...

In an example setup, I have a single directory with many .h and .c(pp)
files imlementing some reusable library. I want to generate
documentation of library's API, which is defined in some of header files in
the directory (the remaining headers define internal functions of the
library, not interesting for me now).

There is a single main header file, which is to be #include-d in applications
built upon the library (library's API), the single header file #include-s
(possibly transitively) all the API header files I am interested in.

I would like to have a new configuration parameter in which I would mention
the main header file. The generated documentation would contain only
constructs from the main header file and all the files transitively
#include-d from it. Other files in the input file set would be left out from
generated documentation.

Let's discuss the feature: should I (or anyone else) implement it? Or can I
solve it in another way (without having to somehow edit all the files in
directory).

TIA,
Milan

[Doxygen-develop] \copydoc and REPEAT_BRIEF=yes

[<sig...@id...>]

When REPEAT_BRIEF is set to yes the brief description is part of the
detailed description and shuld as such be included by \copydoc.

I whould also very much like to see a \clonedoc or \copy-all-doc that whould
allow you to have a function (or in my case a macro) that has the exact same
documentation as another function.

Sigmund Augdal

[Doxygen-develop] Czech translator updated -- trcz.zip

[Petr P. <Pr...@sk...>]

New since 1.3.3 implemented.
Note: I do not use the search engine, so the text
translation is only the guess based on the comments
in the source.

--=20
Petr Prikryl (prikrylp at skil dot cz)

Re: [Doxygen-develop] Doxygen taking longer to run?

[Dimitri v. H. <di...@st...>]

On Mon, Aug 11, 2003 at 12:52:53PM +0100, Edmund Green wrote:
> Attached is my suggested patch for eliminating a few redundant calls to 
> resolveTypeDef

Thanks for looking into this. As you have noticed, the resolution of
typedefs and classes has evolved into something quite complex, and as you
demonstrated that it is/can be a bottleneck, I agree it is time to 
rethink the design.

> I've also been thinking a little more about the speed problem, and if 
> I've understood it correctly then changing getResolveClassRecursive from 
> iterating through all the visible namespaces searching for matching 
> names, to doing a global lookup of all matching local names (i.e. RHS of 
> the name, against RHS of all full names) and then searching within the 
> list of matching names for the best matching namespace could be a lot 
> faster in the typical case where there is only one instance of the local 
> name. It would also remove the need for recursion.
> 
> This would involve adding a global map of lists of fully qualified names 
> indexed by local-name - e.g. some pseodo code for getting a matching 
> class name with this mechanism (ignoring typedefs, and other technicalities)
> 
> ClassDef *getResolvedClass(
>                            Definition *scope,
>                            QCString name,
>                            ...
>                           )
> {
>   String localName = name with any namespace prefix stripped off;
>   String explicitNs = any namespace prefix from the name;
> 
>   List<ClassDef*> *possibleMatches = globalMapOfNames.find(localName);
> 
>   ClassDef* bestMatch = 0;
>   for possibleName in possibleMatches
>   {
>     if possibleName is better match than bestMatch for name from scope
>     {
>       bestMatch = possibleName;
>     }
>   }
>   return bestMatch;
> }
> 
> Admittedely the test inside the loop is slightly awkard when taking in 
> to account "using" namespaces, but it would seem to mostly be a case of 
> matching the left hand side of the possible name against the left-most 
> portion of the scope, and the right hand side against the name, and 
> seeing if any remaining unaccounted for bits in possibleName can be made 
> up from the available imported namespaces.
> 
> I'd expect this to be a lot faster as possibleMatches would typically 
> only have a single entry for most C++ and Java code - though there are a 
> few cases, such as defining call-back interfaces as 
> inner-classes/structs all with the same local name, which would then 
> give longer lists to linearly search through which would also be 
> expected to grow in length approximately linearly with the size of the 
> project (Looking at one of our projects I only found a couple of 
> duplicated class names out of several hundred classes - with the worst 
> case being used in 13 different scopes)

I do something like this for members now. I have two maps, one 
for file/namespace members and one for class members. What you suggest sounds
like a generalization of this, making it one map for all symbols, which could indeed
make a lot of things simpler in doxygen. The downside is that it is a lot of work,
so we should find a way to introduce this gradually.

Regards,
  Dimitri

Re: [Doxygen-develop] Doxygen taking longer to run?

[Edmund G. <ed...@gr...>]

Attached is my suggested patch for eliminating a few redundant calls to 
resolveTypeDef


I've also been thinking a little more about the speed problem, and if 
I've understood it correctly then changing getResolveClassRecursive from 
iterating through all the visible namespaces searching for matching 
names, to doing a global lookup of all matching local names (i.e. RHS of 
the name, against RHS of all full names) and then searching within the 
list of matching names for the best matching namespace could be a lot 
faster in the typical case where there is only one instance of the local 
name. It would also remove the need for recursion.

This would involve adding a global map of lists of fully qualified names 
indexed by local-name - e.g. some pseodo code for getting a matching 
class name with this mechanism (ignoring typedefs, and other technicalities)

ClassDef *getResolvedClass(
                            Definition *scope,
                            QCString name,
                            ...
                           )
{
   String localName = name with any namespace prefix stripped off;
   String explicitNs = any namespace prefix from the name;

   List<ClassDef*> *possibleMatches = globalMapOfNames.find(localName);

   ClassDef* bestMatch = 0;
   for possibleName in possibleMatches
   {
     if possibleName is better match than bestMatch for name from scope
     {
       bestMatch = possibleName;
     }
   }
   return bestMatch;
}

Admittedely the test inside the loop is slightly awkard when taking in 
to account "using" namespaces, but it would seem to mostly be a case of 
matching the left hand side of the possible name against the left-most 
portion of the scope, and the right hand side against the name, and 
seeing if any remaining unaccounted for bits in possibleName can be made 
up from the available imported namespaces.

I'd expect this to be a lot faster as possibleMatches would typically 
only have a single entry for most C++ and Java code - though there are a 
few cases, such as defining call-back interfaces as 
inner-classes/structs all with the same local name, which would then 
give longer lists to linearly search through which would also be 
expected to grow in length approximately linearly with the size of the 
project (Looking at one of our projects I only found a couple of 
duplicated class names out of several hundred classes - with the worst 
case being used in 13 different scopes)

Edmund Green.
http://www.greenius.ltd.uk/

[Doxygen-develop] Doxygen taking longer to run? (long msg)

[Edmund G. <ed...@gr...>]

Doxygen seems to have gotten quite a lot slower in the more recent 
versions than it used to - with one of our projects it now takes 3 times 
as long to document it as to compile it! I'm considering looking in to 
this, and am posting this to see if I'm heading in the right direction, 
and if anybody else has already looked at the problem.

First of all I've tried downloading an older version of doxygen to check 
whether it really has got that much slower or not. Both doxygens were 
configured --english-only and --release, and compiled with gcc3.2.2.

doxygen-1.2.10 (./configure --english-only --release)

small project             big project
real    0m55.423s         real    10m5.203s
user    0m26.060s         user    4m40.320s
sys     0m3.010s          sys     0m33.020s

latest
doxygen 1.3.3-20030808 (./configure --english-only --release)

small project             big project
real    1m8.084s          real    136m3.918s
user    0m33.610s         user    66m38.160s
sys     0m3.710s          sys     0m39.490s

approximate ratios of (user+sys) time:
small project             big project
         1.3 times longer          13 times longer

note that they only got about 50% of the CPU as I'm profiling doxygen on 
the large project in the background, so the "real" time is not that 
meaningful.
As a (very) rough guide to the sizes of these project, the small one is 
outputting 363 html files (without verbatim header), the big project 
1843 html files (with verbatim headers).
Both projects are using nested structs and namespaces everywhere, and 
the bigger one is also using a lot of templates and typedefs. Both 
projects are also using dot for heirarchy and collaboration charts.

I've profiled doxygen on the small project.
| aside : I did this by editing tmake/lib/linux-g++/tmake.cong to set
| the following and then configuring/building as --debug
|
| TMAKE_CFLAGS_DEBUG	= -g -fprofile-arcs -ftest-coverage -pg
| TMAKE_LFLAGS_DEBUG	= -g -pg
| is this the easiest way to do it? and a sensible set of options?

The relevant looking parts of the output from gprof ("..." where I have 
cut uninteresting looking bits) are:

index % time    self  children    called     name
                                                  <spontaneous>
[1]     30.8    0.00   15.24                 main [1]
                 0.00   11.45       1/1           generateOutput() [2]
                 0.00    3.78       1/1           parseInput() [18]
...
-----------------------------------------------
                 0.00   11.45       1/1           main [1]
[2]     23.1    0.00   11.45       1         generateOutput() [2]
                 0.00    7.75       1/1 
generateNamespaceDocs() [9]
                 0.00    3.15       1/1           generateFileDocs() [20]
                 0.00    0.49       1/1           generateClassDocs() [59]
...
-----------------------------------------------
                                                  <spontaneous>
[3]     22.4   11.07    0.00                 __fetch_gcov_type [3]
-----------------------------------------------
                 0.00    0.00       9/30685       codeYYlex() [307]
                 0.00    0.01      18/30685 
generateClassOrGlobalLink(BaseCodeDocInterface&, char*, bool) [478]
                 0.00    0.11     320/30685 
isVarWithConstructor(Entry*) [132]
                 0.00    0.41    1152/30685       getDefs(QCString 
const&, QCString const&, char const*, MemberDef*&, ClassDef*&, 
FileDef*&, NamespaceDef*&, GroupDef*&, bool, FileDef*, bool) [61]
                 0.00    0.81    2269/30685 
findClassRelation(Entry*, ClassDef*, BaseInfo*, QDict<int>*, 
FindBaseClassRelation_Mode, bool) <cycle 1> [29]
                 0.00    1.05    2925/30685 
findClassWithinClassContext(ClassDef*, QCString const&) [37]
                 0.00    8.59   23992/30685 
linkifyText(TextGeneratorIntf const&, Definition*, char const*, char 
const*, bool, bool) [7]
[4]     22.2    0.00   10.98   30685 
getResolvedClass(Definition*, char const*, bool*, QCString*) [4]
                 0.13   10.82   30685/30685 
getResolvedClassRecursive(Definition*, char const*, bool*, QCString*) [5]
                 0.00    0.03   30685/30687 
QDict<Definition>::clear() [256]
-----------------------------------------------
                               112827 
getResolvedClassRecursive(Definition*, char const*, bool*, QCString*) [5]
                 0.13   10.82   30685/30685 
getResolvedClass(Definition*, char const*, bool*, QCString*) [4]
[5]     22.1    0.13   10.82   30685+112827 
getResolvedClassRecursive(Definition*, char const*, bool*, QCString*) [5]
                 0.48    7.42  461962/462331 
resolveTypeDef(Definition*, QCString const&, Definition**) [8]
                 0.02    1.35  902261/1038104 
QString::QString[in-charge](QArray<char> const&) [30]
                 0.01    0.43  462255/535733 
SDict<ClassDef>::find(char const*) [58]
                 0.01    0.36  676607/2105537 
QDict<Definition>::find(QString const&) const [36]
-----------------------------------------------
                                                  <spontaneous>
[6]     21.2   10.50    0.00                 __store_gcov_type [6]
-----------------------------------------------
...
[7]     19.2    0.00    9.50    3487 
linkifyText(TextGeneratorIntf const&, Definition*, char const*, char 
const*, bool, bool) [7]
                 0.00    8.59   23992/30685 
getResolvedClass(Definition*, char const*, bool*, QCString*) [4]
...
-----------------------------------------------
                              1493786 
resolveTypeDef(Definition*, QCString const&, Definition**) [8]
                 0.00    0.01     369/462331 
findUsedClassesForClass(Entry*, ClassDef*, ClassDef*, bool, 
ArgumentList*, QDict<int>*) <cycle 1> [78]
                 0.48    7.42  461962/462331 
getResolvedClassRecursive(Definition*, char const*, bool*, QCString*) [5]
[8]     16.0    0.48    7.43  462331+1493786 resolveTypeDef(Definition*, 
QCString const&, Definition**) [8]
                 0.11    2.47 2633099/2633099 
SDict<MemberName>::find(char const*) [23]
                 0.02    1.38 1428683/1428930 
NamespaceDef::findInnerCompound(char const*) [34]
                 0.34    0.39 1764027/1777806 
getScopeFragment(QCString const&, int, int*) [40]
...

(I think my mail program will wrap the above at 80 columns, so apologies 
if it is mangled somewhat)

My interpretation of this is that of the 15.2 seconds spent exectuting 
doxygen code, 10.8 of those seconds were spent in 
getResolvedClassRecursive(Definition*, char const*, bool*, QCString*)
Of those spent in getResolvedClassRecursive, 7.4 were then spent in 
resolveTypeDef(Definition*, QCString const&, Definition**) [8]


This is the first time I've delved in to the doxygen code, and so am not 
very familier with any of its data structures yet.
Can Dmitri confirm that I'm understanding the overal functionality of 
these two functions so far, based on this pseodo code/english 
description (ignoring for now lots of technicalities handled in the code)

/*
  * find the fully qualified class name refered to by the input class
  * or typedef name against the input scope.
  * loops through scope and each of its parent scopes looking for a
  * match against the input name. Also recursivly calls itself to check
  * against any imported namespaces in each scope being checked.
  */
ClassDef *getResolvedClassRecursive(
                            Definition *scope,
                            QCString name,
                            ...
                           )
{
   do
   {
     check for typedef with call to resolveTypeDef with name against scope
     if name was a typedef
     {
       if result is itself a typedef
       {
         repeatedly call resolveTypeDef with result against scope, until 
a non-typedef result is found
       }
       return result.
     }
     else name was not a typedef
     {
       try ${scope}::${name} and return that if found.
       otherwise
       {
         check name against all classes imported with a "using 
CLASSNAME", and return if found
         for each namespace imported in this scope with a "using 
namespace", recursivly try getResolvedClassRecursive with the used 
namespace, returning result if found
       }
     }
     scope = scope->getOuterScope()
   } while(scope)

   no match found, return 0
}

/*
  * loop through context and each of its parent contexts looking for a 
match against qualified name
  */
QCString resolveTypeDef(Definition *context,
                         const QCString &qualifiedName,
                         Definition **typedefContext)
{
   resName = qualifiedName stripped of any explicit scope prefixes

   MemberDef *md = 0;
   while(context && !md)
   {
     // step 1: get the right scope
     setup resScope to be the right scope from context, and any explicit 
scope in qualifiedName
     // step 2: get the member
     lookup resName in resScope in appropriate dictionary, putting 
result in md

     context=context->getOuterScope()
   }

   if md, then return mf->typeString()
   otherwise return 0;
}

Questions/suggestions so far:
   If "resolveTypeDef" is checking against the input context and all of 
its parent contexts, then the entire check for a typedef in 
getResolvedClassRecursive can be taken outside of the "do{ } 
while(scope)" loop. I've tried this change and re-run doxygen on the 
small project - in this case it reduced the time spent in resolveTypeDef 
by over 50%, an alledged 25% improvement on the total execution time 
spent in doxygen. Is this really a safe change? There are no changes 
that I can see by diff'ing the output with and without the change for 
the small project (after filtering out the "Generated on" lines, 
obviously), but that project is not using many typedefs.


Bits I don't understand :
   I'm still somewhat lost in trying to understand the "resolveTypeDef" 
function. "step 1: get the right scope" is doing something far more 
complicated than merely taking the current scope and appending any 
explicitly specified scope from the qualifiedName to it. Why is this 
necessary, or why is the code for resolving typedefs so different from 
that for resolving classes? - I guess maybe I should start again and 
look at doxygen from the beginnning rather than just diving straight in 
like this though.
   why isn't there a "goto found;" at util.cpp:672 instead of a break 
after successfully matching against an imported class? otherwise can't 
util.cpp:686 still get exectuted and the result lost? or have I missed 
something here.


Edmund Green.

Re: [Doxygen-develop] Proposal for extension to doxygen

[Dimitri v. H. <di...@st...>]

Hi Ian,

Thanks for the patch. It'll be included in the next CVS update.

Regards,
  Dimitri

On Thu, Aug 07, 2003 at 05:24:43PM +0100, Ian Scott wrote:
> Doxygeners,
> 
> I have implemented a /relatesalso command as discussed in previous emails.
> 
> The patches for the mods are included and implements as follows
> cd $doxygen/src; patch <~/src.patch
> cd $doxygen/doc; patch <~/doc.patch
> cd $doxygen/examples; patch <~/examples.patch
> 
> I have made changes to the scanner - to detect the /relatesalso command.
> As suggested I have added a relatesDup bool attribute to the Entry class.
> This is set to true when the \relatesalso command is detected.
> 
> The MemberDef class has had an extra ClassDef *related_also attribute added.
> This is currently used to indicate that normal global/file function
> definition has been marked \relatesalso so that it doesn't get incorrectly
> processed by transferRelatedFunctionDocumentation. However, in future it
> could be used to provide a hyperlink from the global function documentation
> to the documentation of the same function in the class, and maybe remove one
> of the unnecessary full function documentation blocks.
> 
> The changes to doxygen.cpp have following effect:
> 1. Identify entries marked with relatesalso as both class and global
> documentation in buildFunctionList and findMember
> 2. Don't mark the relatesalso entries EMPTY after processing by
> buildFunctionList, so that it can be picked up by
> transferRelatedFunctionDocumentation
> 3. Provide relevant debug information with the Debug:: approach.
> 
> I have also included relevant changes to the documentation and examples
> files.
> 
> I have tested the code on our own code base (50 Mb source -> 167 Mb doxygen
> produced html), and the existing examples in doxygen. The modified doxygen
> produced identical html in both. I also replaced all the instances of
> /relates with /relatesalso in own codebase. Doxygen ran with identical Log
> output, and produced the desired html output in the cases I checked.
> 
> To encourage you to accept this patch, I should explain its usefulness.
> Our codebase is a library for computer vision researchers consisting of a
> large number of classes representing data, and an even larger number of
> functions representing algorithms for the data. The algorithms are in files
> and directories according to some categorisation. Lots of changes are made
> to the algorithms, not so many to the classes. We would like users to have
> two routes to finding any algorithm, through the class page to find the
> algorithms that apply to that class, any through the file page to find
> algorithms in a certain category. Using /relatesalso is a much cleaner
> method of generating the necessary documentation, than say adding lots of
> /sa to the class documentation every time an algorithm is changed.
> 
> Many thanks,
> 
> Ian Scott
> VXL developer.
> 

Re: [Doxygen-develop] Proposal for extension to doxygen

[Ian S. <ian...@st...>]

Doxygeners,

I have implemented a /relatesalso command as discussed in previous emails.

The patches for the mods are included and implements as follows
cd $doxygen/src; patch <~/src.patch
cd $doxygen/doc; patch <~/doc.patch
cd $doxygen/examples; patch <~/examples.patch

I have made changes to the scanner - to detect the /relatesalso command.
As suggested I have added a relatesDup bool attribute to the Entry class.
This is set to true when the \relatesalso command is detected.

The MemberDef class has had an extra ClassDef *related_also attribute added.
This is currently used to indicate that normal global/file function
definition has been marked \relatesalso so that it doesn't get incorrectly
processed by transferRelatedFunctionDocumentation. However, in future it
could be used to provide a hyperlink from the global function documentation
to the documentation of the same function in the class, and maybe remove one
of the unnecessary full function documentation blocks.

The changes to doxygen.cpp have following effect:
1. Identify entries marked with relatesalso as both class and global
documentation in buildFunctionList and findMember
2. Don't mark the relatesalso entries EMPTY after processing by
buildFunctionList, so that it can be picked up by
transferRelatedFunctionDocumentation
3. Provide relevant debug information with the Debug:: approach.

I have also included relevant changes to the documentation and examples
files.

I have tested the code on our own code base (50 Mb source -> 167 Mb doxygen
produced html), and the existing examples in doxygen. The modified doxygen
produced identical html in both. I also replaced all the instances of
/relates with /relatesalso in own codebase. Doxygen ran with identical Log
output, and produced the desired html output in the cases I checked.

To encourage you to accept this patch, I should explain its usefulness.
Our codebase is a library for computer vision researchers consisting of a
large number of classes representing data, and an even larger number of
functions representing algorithms for the data. The algorithms are in files
and directories according to some categorisation. Lots of changes are made
to the algorithms, not so many to the classes. We would like users to have
two routes to finding any algorithm, through the class page to find the
algorithms that apply to that class, any through the file page to find
algorithms in a certain category. Using /relatesalso is a much cleaner
method of generating the necessary documentation, than say adding lots of
/sa to the class documentation every time an algorithm is changed.

Many thanks,

Ian Scott
VXL developer.


> Date: Mon, 21 Jul 2003 08:58:39 +0200
> From: Dimitri van Heesch <di...@st...>
>
> On Thu, Jul 17, 2003 at 07:06:44PM +0100, Ian Scott wrote:
> > ...
> > /relates also
> > Secondly if not, would you accept a patch to provide such
> functionality
> > (assuming it was well written etc.?)
>
> Yes.
>
> >
> > 3. Add a new special command (e.g. \relatesalso) that
> behaves as described
> > above.
>
> I would opt for number 3.
>
> > Forthly, have you any hints on how to implement it.
> >
> > We would find this functionality very useful, and have a
> small amount of
> > time to implement it - assuming it is relatively staightforward.
>

Re: [Doxygen-develop] out of memory - doxytag 1.3.3 / Windows XP

[Dimitri v. H. <di...@st...>]

On Thu, Jul 31, 2003 at 09:28:59AM -0400, MCALLISTER,RONAN (HP-FtCollins,ex1) wrote:
>       Hello,
> 
> I'm testing/playing with doxygen 1.3.3 / Windows  XP  on a project of
> "significant" size:
>  
> Running doxytag on a Windows XP system with 2G of phys memory (1.7G
> available) on a *Large* bunch of HTML files generated by doxygen gives an
> "out of memory" error only after parsing a few files.
>  
> Can this be avoided?

Not at the moment, but I'm in the process of redesigning the search engine.
The indexing should then require much less memory, and the search engine 
should be easier to configure.

Regards, 
  Dimitri

[Doxygen-develop] out of memory - doxytag 1.3.3 / Windows XP

[MCALLISTER,RONAN (HP-FtCollins,ex1) <ron...@hp...>]

      Hello,

I'm testing/playing with doxygen 1.3.3 / Windows  XP  on a project of
"significant" size:
 
Running doxytag on a Windows XP system with 2G of phys memory (1.7G
available) on a *Large* bunch of HTML files generated by doxygen gives an
"out of memory" error only after parsing a few files.
 
Can this be avoided?
 
I'd like to use the search engine (very important for this source - too
difficult to navigage large codebase without it) and have spent 2 days
running doxygen to create the HTML, .dot, .latex, etc.
 
Thank you for ideas/help!    BTW I can change source... can I fix this?
Can doxytag make use of VM or memory beyond the DOS limit?
 
You can e-mail me at ron...@hp...
<mailto:ron...@hp...>  if you wish.
 
Any ideas appreciated!
 
Ronan

Re: [Doxygen-develop] gcc 3.3 patch

[Dimitri v. H. <di...@st...>]

On Tue, Jul 22, 2003 at 02:21:02AM -0700, James Michael DuPont wrote:
> Dear All,
> 
> I have just compiled doxygen with the new gcc (3.3)
> it has a problem with a union of objects with a constructor.

This looks more like the bison bug again (there was a bug in the 
bison version range 1.30 to 1.34, so please check this first using
bison -V).

Regards,
  Dimitri

Re: [Doxygen-develop] gcc 3.3 patch

[James M. D. <mdu...@ya...>]

Please do not apply this patch yet, 
when i run doxygen, it hangs the entire system.
I think it might have something to do with this command : 

> +    operator CPPValueParser &  ()
> +       {
> +          static CPPValueParser ret = *this;
> +          return ret;
> +       }

mike
--- James Michael DuPont <mdu...@ya...> wrote:
> Dear All,
> 
> I have just compiled doxygen with the new gcc (3.3)
> it has a problem with a union of objects with a constructor.
> 
> CPPValue
> 
> I have removed the constructor, and put it into a derived class
> CppValue2.
> 
> The class CppValueParser is used by the Parser directly.
> 
> The users of the CPPValue now use CPPValue2, the parsers uses
> CppValueParser.
> 
> This all has the effect of isolating the constructor from the parser,
> but making them work togeather. Surely this can be done better, just
> a
> quick hack..
> 
> 
> Mike
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com> diff -u src/constexp.y
../src/constexp.y
> --- src/constexp.y	Mon Jan 20 04:40:09 2003
> +++ ../src/constexp.y	Tue Jul 22 11:11:41 2003
> @@ -26,7 +26,7 @@
>  #define MSDOS
>  #endif
>  
> -#define YYSTYPE CPPValue
> +#define YYSTYPE CPPValueParser
>  
>  #include <stdio.h>
>  #include <stdlib.h>
> @@ -93,7 +93,7 @@
>  		       { $$ = $1; }
>                       | logical_or_expression TOK_OR
> logical_and_expression
>  		       {
> -			 $$ = CPPValue( (long)((long)$1 || (long)$3) );
> +			 $$ = CPPValue2( (long)((long)$1 || (long)$3) );
>  		       }
>  ;
>  
> @@ -101,7 +101,7 @@
>  			{ $$ = $1; }
>  		      | logical_and_expression TOK_AND inclusive_or_expression
>  			{
> -			  $$ = CPPValue( (long)((long)$1 && (long)$3) );
> +			  $$ = CPPValue2( (long)((long)$1 && (long)$3) );
>  			}
>  ;
>  
> @@ -110,7 +110,7 @@
>  		       | inclusive_or_expression TOK_BITWISEOR 
>                           exclusive_or_expression
>  			 { 
> -			   $$ = CPPValue( (long)$1 | (long)$3 );
> +			   $$ = CPPValue2( (long)$1 | (long)$3 );
>  			 }
>  ;
>  
> @@ -118,7 +118,7 @@
>  			 { $$ = $1; }
>  		       | exclusive_or_expression TOK_BITWISEXOR and_expression
>  			 {
> -			   $$ = CPPValue( (long)$1 ^ (long)$3 );
> +			   $$ = CPPValue2( (long)$1 ^ (long)$3 );
>  			 }
>  ;
>  
> @@ -126,7 +126,7 @@
>  		{ $$ = $1; }
>  	      | and_expression TOK_AMPERSAND equality_expression
>  		{ 
> -		  $$ = CPPValue( (long)$1 & (long)$3 );
> +		  $$ = CPPValue2( (long)$1 & (long)$3 );
>  		}
>  ;
>  
> @@ -134,11 +134,11 @@
>  		     { $$ = $1; }
>  		   | equality_expression TOK_EQUAL relational_expression
>  		     { 
> -		       $$ = CPPValue( (long)((double)$1 == (double)$3) );
> +		       $$ = CPPValue2( (long)((double)$1 == (double)$3) );
>  	             }
>  		   | equality_expression TOK_NOTEQUAL relational_expression
>  		     {
> -                       $$ = CPPValue( (long)((double)$1 !=
> (double)$3) );
> +                       $$ = CPPValue2( (long)((double)$1 !=
> (double)$3) );
>  		     }
>  ;
>  
> @@ -146,21 +146,21 @@
>  		       { $$ = $1; }
>  		     | relational_expression TOK_LESSTHAN shift_expression
>  		       { 
> -			 $$ = CPPValue( (long)((double)$1 < (double)$3) );
> +			 $$ = CPPValue2( (long)((double)$1 < (double)$3) );
>  		       }
>  		     | relational_expression TOK_GREATERTHAN shift_expression
>  		       {
> -                         $$ = CPPValue( (long)((double)$1 >
> (double)$3) );
> +                         $$ = CPPValue2( (long)((double)$1 >
> (double)$3) );
>  		       }
>  		     | relational_expression TOK_LESSTHANOREQUALTO
>  		       shift_expression
>  		       {
> -		         $$ = CPPValue( (long)((double)$1 <= (double)$3) );
> +		         $$ = CPPValue2( (long)((double)$1 <= (double)$3) );
>  		       }
>  		     | relational_expression TOK_GREATERTHANOREQUALTO
>  		       shift_expression
>  		       {
> -			 $$ = CPPValue( (long)((double)$1 >= (double)$3) );
> +			 $$ = CPPValue2( (long)((double)$1 >= (double)$3) );
>  		       }
>  ;
>  
> @@ -168,11 +168,11 @@
>  		  { $$ = $1; }
>  		| shift_expression TOK_SHIFTLEFT additive_expression
>  		  {
> -		    $$ = CPPValue( (long)$1 << (long)$3 );	
> +		    $$ = CPPValue2( (long)$1 << (long)$3 );	
>  		  }
>  		| shift_expression TOK_SHIFTRIGHT additive_expression
>  		  {
> -		    $$ = CPPValue( (long)$1 >> (long)$3 );
> +		    $$ = CPPValue2( (long)$1 >> (long)$3 );
>  		  }
>  ;
>  
> @@ -182,22 +182,22 @@
>  		     {
>  		       if (!$1.isInt() || !$3.isInt())
>  		       {
> -		         $$ = CPPValue( (double)$1 + (double)$3 );
> +		         $$ = CPPValue2( (double)$1 + (double)$3 );
>  		       }
>  		       else	
>  		       {
> -		         $$ = CPPValue( (long)$1 + (long)$3 );
> +		         $$ = CPPValue2( (long)$1 + (long)$3 );
>  		       }
>  		     }
>  		   | additive_expression TOK_MINUS multiplicative_expression
>  		     {
>  		       if (!$1.isInt() || !$3.isInt())
>  		       {
> -		         $$ = CPPValue( (double)$1 - (double)$3 );
> +		         $$ = CPPValue2( (double)$1 - (double)$3 );
>  		       }
>  		       else	
>  		       {
> -		         $$ = CPPValue( (long)$1 - (long)$3 );
> +		         $$ = CPPValue2( (long)$1 - (long)$3 );
>  		       }
>  		     }
>  ;
> @@ -208,31 +208,31 @@
>  			   { 
>  			     if (!$1.isInt() || !$3.isInt())
>  			     {
> -			       $$ = CPPValue( (double)$1 * (double)$3 );
> +			       $$ = CPPValue2( (double)$1 * (double)$3 );
>  			     }
>  			     else
>  			     {
> -			       $$ = CPPValue( (long)$1 * (long)$3 );
> +			       $$ = CPPValue2( (long)$1 * (long)$3 );
>  			     }
>  			   }
>  			 | multiplicative_expression TOK_DIVIDE unary_expression
>  			   { 
>  			     if (!$1.isInt() || !$3.isInt())
>  			     {
> -			       $$ = CPPValue( (double)$1 / (double)$3 );
> +			       $$ = CPPValue2( (double)$1 / (double)$3 );
>  			     }
>  			     else
>  			     {
>  			       long value = $3;
>  			       if (value==0) value=1;
> -			       $$ = CPPValue( (long)$1 / value );
> +			       $$ = CPPValue2( (long)$1 / value );
>  			     }
>  			   }
>  			 | multiplicative_expression TOK_MOD unary_expression
>  			   { 
>  			     long value = $3;
>  			     if (value==0) value=1;
> -			     $$ = CPPValue( (long)$1 % value );
> +			     $$ = CPPValue2( (long)$1 % value );
>  			   }
>  ;
>  
> @@ -243,17 +243,17 @@
>  		| TOK_MINUS unary_expression
>  		  { 
>  		    if ($2.isInt()) 
> -                      $$ = CPPValue(-(long)$2);
> +                      $$ = CPPValue2(-(long)$2);
>                      else
> -		      $$ = CPPValue(-(double)$2);
> +		      $$ = CPPValue2(-(double)$2);
>  		  }
>  		| TOK_TILDE unary_expression
>  		  {
> -		    $$ = CPPValue(~(long)$2);
> +		    $$ = CPPValue2(~(long)$2);
>  		  }
>  		| TOK_NOT unary_expression
>  		  {
> -		    $$ = CPPValue((long)!(long)$2);
> +		    $$ = CPPValue2((long)!(long)$2);
>  		  }
>  ;
>  
> Only in ../src/: constexp.y.~1.21.~
> diff -u src/cppvalue.cpp ../src/cppvalue.cpp
> --- src/cppvalue.cpp	Mon Jan 20 04:40:09 2003
> +++ ../src/cppvalue.cpp	Tue Jul 22 11:00:18 2003
> @@ -21,27 +21,27 @@
>  #include "cppvalue.h"
>  #include "constexp.h"
>  
> -CPPValue parseOctal()
> +CPPValue2 parseOctal()
>  {
>    long val = 0;
>    for (const char *p = g_strToken.data(); *p != 0; p++)
>    {
>      if (*p >= '0' && *p <= '7') val = val * 8 + *p - '0';
>    }
> -  return CPPValue(val);
> +  return CPPValue2(val);
>  }
>  
> -CPPValue parseDecimal()
> +CPPValue2 parseDecimal()
>  {
>    long val = 0;
>    for (const char *p = g_strToken.data(); *p != 0; p++)
>    {
>      if (*p >= '0' && *p <= '9') val = val * 10 + *p - '0';
>    }
> -  return CPPValue(val);
> +  return CPPValue2(val);
>  }
>  
> -CPPValue parseHexadecimal()
> +CPPValue2 parseHexadecimal()
>  {
>    long val = 0;
>    for (const char *p = g_strToken.data(); *p != 0; p++)
> @@ -51,37 +51,37 @@
>      else if (*p >= 'A' && *p <= 'F') val = val * 16 + *p - 'A' + 10;
>    }
>    //printf("parseHexadecimal %s->%x\n",g_strToken.data(),val);
> -  return CPPValue(val);
> +  return CPPValue2(val);
>  }
>  
> -CPPValue parseCharacter() // does not work for '\n' and the alike 
> +CPPValue2 parseCharacter() // does not work for '\n' and the alike 
>  {
>    if (g_strToken[1]=='\\')
>    {
>      switch(g_strToken[2])
>      {
> -      case 'n':  return CPPValue((long)'\n');
> -      case 't':  return CPPValue((long)'\t');
> -      case 'v':  return CPPValue((long)'\v');
> -      case 'b':  return CPPValue((long)'\b');
> -      case 'r':  return CPPValue((long)'\r');
> -      case 'f':  return CPPValue((long)'\f');
> -      case 'a':  return CPPValue((long)'\a');
> -      case '\\': return CPPValue((long)'\\');
> -      case '?':  return CPPValue((long)'\?');
> -      case '\'': return CPPValue((long)'\'');
> -      case '"':  return CPPValue((long)'"');
> +      case 'n':  return CPPValue2((long)'\n');
> +      case 't':  return CPPValue2((long)'\t');
> +      case 'v':  return CPPValue2((long)'\v');
> +      case 'b':  return CPPValue2((long)'\b');
> +      case 'r':  return CPPValue2((long)'\r');
> +      case 'f':  return CPPValue2((long)'\f');
> +      case 'a':  return CPPValue2((long)'\a');
> +      case '\\': return CPPValue2((long)'\\');
> +      case '?':  return CPPValue2((long)'\?');
> +      case '\'': return CPPValue2((long)'\'');
> +      case '"':  return CPPValue2((long)'"');
>        case '0':  return parseOctal();
>        case 'x': 
>        case 'X':  return parseHexadecimal();
>        default:   printf("Invalid escape sequence %s
> found!\n",g_strToken.data()); 
> -                 return CPPValue(0L); 
> +                 return CPPValue2(0L); 
>      }
>    }
> -  return CPPValue((long)g_strToken[1]);
> +  return CPPValue2((long)g_strToken[1]);
>  }
>  
> -CPPValue parseFloat()
> +CPPValue2 parseFloat()
>  {
> -  return CPPValue(atof(g_strToken));
> +  return CPPValue2(atof(g_strToken));
>  }
> Only in ../src/: cppvalue.cpp.~1.23.~
> diff -u src/cppvalue.h ../src/cppvalue.h
> --- src/cppvalue.h	Mon Jan 20 04:40:09 2003
> +++ ../src/cppvalue.h	Tue Jul 22 11:14:22 2003
> @@ -28,9 +28,6 @@
>    
>    
>      enum Type { Int, Float };
> -  
> -    CPPValue(long val=0) : type(Int) { v.l = val; }
> -    CPPValue(double val) : type(Float) { v.d = val; }
>  
>      operator double () const { return type==Int ? (double)v.l : v.d;
> }
>      operator long ()   const { return type==Int ? v.l : (long)v.d;  
> }
> @@ -45,7 +42,7 @@
>          printf("(%f)\n",v.d);
>      }
>  
> -  private:
> +
>      Type type;
>      union {
>        double d;
> @@ -53,10 +50,51 @@
>      } v;
>  };
>  
> -extern CPPValue parseOctal();
> -extern CPPValue parseDecimal();
> -extern CPPValue parseHexadecimal();
> -extern CPPValue parseCharacter();
> -extern CPPValue parseFloat();
> +class CPPValueParser : public CPPValue
> +{
> +   public : 
> +CPPValue &  operator = (CPPValue b)
> +{
> +   type = b.type;
> +   if (type == CPPValue::Int)
> +   {
> +      v.l = b.v.l;
> +   }  
> +   else
> +   {   
> +      v.d = b.v.d;
> +   }
> +   return *this;
> +}
> +
> +};
> +
> +class CPPValue2 : public CPPValue
> +{
> +   public : 
> +    CPPValue2() {type = CPPValue::Int; v.l = 0; }
> +    CPPValue2(long val)  {
> +       type = CPPValue::Int; 
> +       v.l = val; 
> +
> +    }
> +    
> +    CPPValue2(double val)  { 
> +       type = CPPValue::Float; 
> +       v.d = val; 
> +    }
> +
> +    operator CPPValueParser &  ()
> +       {
> +          static CPPValueParser ret = *this;
> +          return ret;
> +       }
> +};
> +
> +extern CPPValue2 parseOctal();
> +extern CPPValue2 parseDecimal();
> +extern CPPValue2 parseHexadecimal();
> +extern CPPValue2 parseCharacter();
> +extern CPPValue2 parseFloat();
>  
>  #endif
> 


=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

[Doxygen-develop] gcc 3.3 patch

[James M. D. <mdu...@ya...>]

Dear All,

I have just compiled doxygen with the new gcc (3.3)
it has a problem with a union of objects with a constructor.

CPPValue

I have removed the constructor, and put it into a derived class
CppValue2.

The class CppValueParser is used by the Parser directly.

The users of the CPPValue now use CPPValue2, the parsers uses
CppValueParser.

This all has the effect of isolating the constructor from the parser,
but making them work togeather. Surely this can be done better, just a
quick hack..


Mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [Doxygen-develop] Doxygen - don't remove whitespace

[Dimitri v. H. <di...@st...>]

On Wed, Jul 16, 2003 at 03:29:01PM -0700, al...@ic... wrote:
> Hello Doxygen developers,
>     I would like to modify the source code for Doxygen so that white space in 
> special documentation blocks is not removed.  This may be as simple as 
> modifying a couple source files but my problem is that I am unfamiliar with 
> flex and bison.  

This can already be done by putting a <pre>...</pre> block around your text.

Regards,
  Dimitri

Re: [Doxygen-develop] Proposal for extension to doxygen

[Dimitri v. H. <di...@st...>]

On Thu, Jul 17, 2003 at 07:06:44PM +0100, Ian Scott wrote:
> First of all let me say thank-you to Dimitri and contributors for this
> wonderful program.
> 
> Our project (vxl.sf.net) uses Doxygen very heavily. We have started using
> the \relates option quite a lot in new code, like this:
> 
> my_func.h
> 
>     /** A simple function.
>      *  Detailed description
>      * \relates my_class
>      */
>     void my_func(my_class &);
> 
> my_class.h
> 
>     /** A simple class.
>      */
>     class my_class { };
> 
> Currently doxygen produces the documentation for my_func and puts it in the
> same page as the documentation for my_class. If the \relates were not there,
> then the documentation for my_func would go in the my_func.h page.
> 
> For various reasons we would like the documentation for my_func to appear in
> both the my_class page and the my_func.f page.
> 
> Firstly is there away of doing this at present? (Using \sa or something
> similar in the my_class comments is not suitable - we need a backwards
> reference in the my_func.h file)

No, doxygen internally maintains a list of all members with global/namespace
scope and a list of all class members. \relates put a member that actually
belongs to the first list in the second list. What you need is to put
the member in both lists.

> Secondly if not, would you accept a patch to provide such functionality
> (assuming it was well written etc.?)

Yes.

> Thirdly if you would accept a patch, how would like like this functionality
> to be used?
> 
> 1. Make it default behaviour for /relates in a function doc-comment to put
> the documentation for that function in both the file (my_func.h)
> documentation and the class documentation.
> 
> 2. Keep default behaviour as normal, but add an option to the control file
> that turns on behaviour as described above
> 
> 3. Add a new special command (e.g. \relatesalso) that behaves as described
> above.

I would opt for number 3.

> Forthly, have you any hints on how to implement it.
> 
> We would find this functionality very useful, and have a small amount of
> time to implement it - assuming it is relatively staightforward.

The \relates command is detected in scanner.l and its argument is stored
in the "relates" member of an Entry. In doxygen.cpp there is a findMember()
function which contains code handling related members. I think the best
way to implement this is to keep the "relates" field, and add a "relatesDup"
boolean field to indicate if the member needs to be duplicated. If the
boolean is TRUE you need to create two new MemberDefs, one for each list.

Regards,
  Dimitri

[Doxygen-develop] New Brazilian Portuguese translator

[FJTC (F. J. T. Chino) <ch...@ic...>]

Hi.

This is the new version of the Brazilian Portuguese translator. I forgot to
update it before the release of the version 1.3.2 because I was busy with my
M. Sc..

See you...
FJTC

----------------------------------------------------------------------
           FJTC (Fabio Jun Takada Chino) - ch...@ic...
      Computer Science - ICMC - University of Sao Paulo - Brazil
              GBDI - Grupo de Base de Dados e Imagens
----------------------------------------------------------------------
Homepage
  http://www.icmc.usp.br/~chino (main)
  http://gbdi.icmc.usp.br/ (GBDI)
  http://www.fjtc.hpg.com.br/ (Anime - Portuguese Only)
  http://www.bbits.hpg.com.br/ (Game Programming - English Only)
======================================================================

[Doxygen-develop] Proposal for extension to doxygen

[Ian S. <ian...@st...>]

First of all let me say thank-you to Dimitri and contributors for this
wonderful program.

Our project (vxl.sf.net) uses Doxygen very heavily. We have started using
the \relates option quite a lot in new code, like this:

my_func.h

    /** A simple function.
     *  Detailed description
     * \relates my_class
     */
    void my_func(my_class &);

my_class.h

    /** A simple class.
     */
    class my_class { };

Currently doxygen produces the documentation for my_func and puts it in the
same page as the documentation for my_class. If the \relates were not there,
then the documentation for my_func would go in the my_func.h page.

For various reasons we would like the documentation for my_func to appear in
both the my_class page and the my_func.f page.

Firstly is there away of doing this at present? (Using \sa or something
similar in the my_class comments is not suitable - we need a backwards
reference in the my_func.h file)

Secondly if not, would you accept a patch to provide such functionality
(assuming it was well written etc.?)

Thirdly if you would accept a patch, how would like like this functionality
to be used?

1. Make it default behaviour for /relates in a function doc-comment to put
the documentation for that function in both the file (my_func.h)
documentation and the class documentation.

2. Keep default behaviour as normal, but add an option to the control file
that turns on behaviour as described above

3. Add a new special command (e.g. \relatesalso) that behaves as described
above.

Forthly, have you any hints on how to implement it.

We would find this functionality very useful, and have a small amount of
time to implement it - assuming it is relatively staightforward.

Many thanks,

Ian Scott.

RE: [Doxygen-develop] Doxygen - don't remove whitespace

[Paul B. <pb...@ka...>]

  This can probably be done if you use HTML to lay out exactly what you
want the comment to look like.  Doxygen does quite a bit of massaging of
the input text, so keeping the whitspace you're talking about intact might
be tricky.  (I dug through the lex portions a few years ago, fun stuff but
not really where I'd want to do any casual hacking..)
  Consider using @brief in place of Abstract, which lets Doxygen
intelligently format your comments in whatever output format you like.
Also, putting @note instead of Note: lets Doxygen know that it's a note
specifically, which it will format properly with a bold heading and such.
@note has a few cousins, in the form of @warning, @bug and @todo, the
latter two of which have the added bonus of being able to be pulled into
separate pages to give you lists of known bugs or work items.
  As a side note, you may want to consider dropping the prefix / on each
line - that's starting a nested comment which isn't strictly allowed in C.
Some compilers accept it without comment and some will choke.

  -P

--
Apologies for sending this from Outlook - my employer's views don't
necessarily reflect my own in any way.

-----Original Message-----
From: dox...@li...
[mailto:dox...@li...]On Behalf Of
al...@ic...
Sent: Wednesday, July 16, 2003 6:29 PM
To: dox...@li...
Cc: al...@ic...
Subject: [Doxygen-develop] Doxygen - don't remove whitespace


Hello Doxygen developers,
    I would like to modify the source code for Doxygen so that white space
in
special documentation blocks is not removed.  This may be as simple as
modifying a couple source files but my problem is that I am unfamiliar
with
flex and bison.  Here is a more concrete example of what I mean:

(from my source code)
/**
/* Abstract:
/*   This function performs calculations for the new viewing frustum
/*
/* Note:
/*   This function expects the *window pointer to point to the current
view
*/

*window calcFrustum(Window* win)



In the corresponding entry for the generated man page, the whitespace,
newlines, and asterisks are removed and it appears as:

*window calcFrustum(Window* win)

  Abstract: This function performs calculations for the new viewing
frustum

  Note: This function expects the *window pointer to point to the current
view




However, I would like it to only have stripped the asterisk (and
preferrable
replace it with whitespace):

*window calcFrustum(Window* win)

  Abstract:
    This function performs calculations for the new viewing frustum

  Note:
    This function expects the *window pointer to point to the current view

Can someone provide incite as to how I can go about changing the source so
that
whitespace is not removed?  Any help would be greatly appreciated.

-Allen
al...@ic...



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Doxygen-develop mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] Re:Doxygen - don't remove whitespace

[Jan R. <jan...@co...>]

Hi Allen,

I think that you are asking a little bit more the a preserving of the 
white spaces.

Even if the white spaces are preserved it would not mean anything in 
the context of HTML.
There has to be HTML tags corresponding to the white space characters.
Example <br> for a new line, &nbsp;  for multiple spaces etc.

On the other hand there can be demand for not preserving white spaces 
because of rigid
rules of writing the source code (80 characters per line max. etc.).

Be careful what do you wish for.

Jan

> Hello Doxygen developers,
>     I would like to modify the source code for Doxygen so that white 
> space in
> special documentation blocks is not removed.  This may be as simple as
> modifying a couple source files but my problem is that I am unfamiliar 
> with
> flex and bison.  Here is a more concrete example of what I mean:
>
> (from my source code)
> /**
> /* Abstract:
> /*   This function performs calculations for the new viewing frustum
> /*
> /* Note:
> /*   This function expects the *window pointer to point to the current 
> view
> */
>
> *window calcFrustum(Window* win)
>
>
>
> In the corresponding entry for the generated man page, the whitespace,
> newlines, and asterisks are removed and it appears as:
>
> *window calcFrustum(Window* win)
>
>   Abstract: This function performs calculations for the new viewing 
> frustum
>
>   Note: This function expects the *window pointer to point to the 
> current view
>
>
>
>
> However, I would like it to only have stripped the asterisk (and 
> preferrable
> replace it with whitespace):
>
> *window calcFrustum(Window* win)
>
>   Abstract:
>     This function performs calculations for the new viewing frustum
>
>   Note:
>     This function expects the *window pointer to point to the current 
> view
>
> Can someone provide incite as to how I can go about changing the 
> source so that
> whitespace is not removed?  Any help would be greatly appreciated.
>
> -Allen
> al...@ic...

[Doxygen-develop] Doxygen - don't remove whitespace

[<al...@ic...>]

Hello Doxygen developers,
    I would like to modify the source code for Doxygen so that white space in 
special documentation blocks is not removed.  This may be as simple as 
modifying a couple source files but my problem is that I am unfamiliar with 
flex and bison.  Here is a more concrete example of what I mean:

(from my source code)
/**
/* Abstract:
/*   This function performs calculations for the new viewing frustum
/*
/* Note:
/*   This function expects the *window pointer to point to the current view
*/

*window calcFrustum(Window* win)



In the corresponding entry for the generated man page, the whitespace, 
newlines, and asterisks are removed and it appears as:

*window calcFrustum(Window* win)

  Abstract: This function performs calculations for the new viewing frustum

  Note: This function expects the *window pointer to point to the current view




However, I would like it to only have stripped the asterisk (and preferrable 
replace it with whitespace):

*window calcFrustum(Window* win)

  Abstract:
    This function performs calculations for the new viewing frustum

  Note:
    This function expects the *window pointer to point to the current view

Can someone provide incite as to how I can go about changing the source so that 
whitespace is not removed?  Any help would be greatly appreciated.

-Allen
al...@ic...