doxygen-users — List for users of doxygen

[Doxygen-users] No "References" list in slots?

[Gordon M. <gm...@us...>]

I'm in the process of documenting a Qt-based application. It seems that 
doxygen doesn't create a "References" list for slots. "Referenced by" is ok. 
Anybody noticed this as well? I'm using the most recent version of doxygen 
(1.2.13.1).

Gordon

[Doxygen-users] No "References" list in slots?

[Gordon M. <ma...@oh...>]

I'm in the process of documenting a Qt-based application. It seems that 
doxygen doesn't create a "References" list for slots. "Referenced by" is ok. 
Anybody noticed this as well? I'm using the most recent version of doxygen 
(1.2.13.1).

Gordon

[Doxygen-users] Doxygen RPMS for RedHat 7.2

[Emilio R. <Emi...@ma...>]

Re-sent mail: some stupid programs believe *.spec to be a virus!!!!

Hallo!
Actually doxygen/doxywizard RPMS are freezed at release 1.2.11;
I've found easy to recreate a complete set of RPMS (src + bin) starting
from RawHide SRPM (available on rpmfind.net or RedHat ftp site), deleting
the qt3 patch and using the attached (modified) .spec file

Emilio Riva

(See attached file: doxygen_spec.txt)

[Doxygen-users] Virus rejected

[<ro...@vo...>]

Received: from [198.76.25.3] (HELO nns.voyanttech.com)
  by voyanttech.com (CommuniGate Pro SMTP 3.4b3)
  with SMTP id 1774113 for gle...@vo...; Thu, 10 Jan 2002 03:36:26 -0700
Received: from usw-sf-list1.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252])
	by nns.voyanttech.com (8.9.3+Sun/8.9.3) with SMTP id EAA26339
	for <gle...@vo...>; Thu, 10 Jan 2002 04:36:59 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=usw-sf-list1.sourceforge.net)
	by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian))
	id 16OcX5-0005Az-00; Thu, 10 Jan 2002 02:34:03 -0800
Received: from cvis29.marconicomms.com ([195.99.244.61])
	by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian))
	id 16OcW5-0004qV-00
	for <dox...@li...>; Thu, 10 Jan 2002 02:33:01 -0800
Received: from cvis06.marconicomms.com (unverified) by cvis29.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T01...@cv...> for <dox...@li...>;
 Thu, 10 Jan 2002 10:32:46 +0000
Received: from cvdgwy01.uk.marconicomms.com by cvis06.marconicomms.com with ESMTP
 (8.10.2+Sun/cvms-34) id g0AAWlN22710; Thu, 10 Jan 2002 10:32:47 GMT
To: dox...@li...
From: "Emilio Riva" <Emi...@ma...>
Message-ID: <OF2...@uk...>
X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at
 10/01/2002 10:32:40
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=C1256B3D00396FC38f9e8a93df938690918cC1256B3D00396FC3"
Content-Disposition: inline
Subject: [Doxygen-users] Doxygen RPMS for RedHat 7.2
Sender: dox...@li...
Errors-To: dox...@li...
X-BeenThere: dox...@li...
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:dox...@li...?subject=help>
List-Post: <mailto:dox...@li...>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/doxygen-users>,
	<mailto:dox...@li...?subject=subscribe>
List-Id: <doxygen-users.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/doxygen-users>,
	<mailto:dox...@li...?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=doxygen-users>
X-Original-Date: Thu, 10 Jan 2002 11:32:25 +0100
Date: Thu, 10 Jan 2002 11:32:25 +0100

--0__=C1256B3D00396FC38f9e8a93df938690918cC1256B3D00396FC3
Content-type: text/plain; charset=us-ascii

Hallo!
Actually doxygen/doxywizard RPMS are freezed at release 1.2.11;
I've found easy to recreate a complete set of RPMS (src + bin) starting
from RawHide SRPM (available on rpmfind.net or RedHat ftp site), deleting
the qt3 patch and using the attached (modified) .spec file

Emilio Riva

(See attached file: doxygen.spec)
--0__=C1256B3D00396FC38f9e8a93df938690918cC1256B3D00396FC3
Content-type: application/octet-stream; 
	name="doxygen.spec"

FOR ANTI-VIRUS SECURITY, THIS EMAIL HAS BEEN CLEANED.

REASON:
THE ATTACHMENT CONTAINED AN INVALID EXTENSION OF '.spec'

[Doxygen-users] Doxygen RPMS for RedHat 7.2

[Emilio R. <Emi...@ma...>]

Hallo!
Actually doxygen/doxywizard RPMS are freezed at release 1.2.11;
I've found easy to recreate a complete set of RPMS (src + bin) starting
from RawHide SRPM (available on rpmfind.net or RedHat ftp site), deleting
the qt3 patch and using the attached (modified) .spec file

Emilio Riva

(See attached file: doxygen.spec)

[Doxygen-users] Segmentation fault with binaries on SOS 5.8

[Lars v. W. <von...@lf...>]

Hello,

we're using doxygen for quite some time now. Yesterday, I downloaded a
new binary
1.2.13 for Solaris 8 from the doxygen pages. It gives me a segmentation
fault in the
middle of the process:

> Searching for enumerations...
> Searching for member function documentation...
> /users/modkit/RealmsDevelopment/Source/Cheops/src/cheops/numeric/eso_variable_i.cc:72: Warning: no matching class member found for
>   EsoVariable_i::EsoVariable_i(const string &name, long index, long dimension, Cheops::Eso::Eso *eso, vector< double > initial_coefficients, Numeric::SupportType support_type=Numerics::UNSPECIFIED)
> Possible candidates:
> Segmentation Fault (core dumped)

Anyone knows help? Doxygen 1.2.5 on Linux works fine with more or less
the same set of C++ sources.

Lars

Re: [Doxygen-users] support japanase rtf

[Haruyuki O. <oh...@is...>]

I want to fix this problem, too.
I tried to fix it. But it's not easy.

* Currently, translator_jp.h does not implement some methods required to
generate Japanese RTF.
* Doxygen supports Japanese EUC code by default. To support both EUC and
Shit-JIS, more efforts will be needed.

  ----- Original Message -----
  From: chen bin
  To: dox...@li...
  Sent: Thursday, January 10, 2002 12:25 PM
  Subject: [Doxygen-users] support japanase rtf


  hi=A3=BA
  when I select Japanase in the language option, I can not get readable
rtf( read by word2000, at win2000 pro)

  best regards
  chen bin

[Doxygen-users] support japanase rtf

[chen b. <ch...@ya...>]

aGmjug0Kd2hlbiBJIHNlbGVjdCBKYXBhbmFzZSBpbiB0aGUgbGFuZ3VhZ2Ugb3B0aW9uLCBJIGNh
biBub3QgZ2V0IHJlYWRhYmxlIHJ0ZiggcmVhZCBieSB3b3JkMjAwMCwgYXQgd2luMjAwMCBwcm8p
DQoNCmJlc3QgcmVnYXJkcw0KY2hlbiBiaW4NCg==

RE: [Doxygen-users] sharing bits of a configuration file

[Dan M. <dm...@Cr...>]

Yes, this is very easy to do. Check out the documentation for
@INCLUDE=<filename>, at the very beginning of the Configuration section of
the doxygen manual. Configuration options can be changed, last setting wins.
This means that you can have a common set of configuration settings in a
file, include it in another file, and add to or override any settings you
like.

> -----Original Message-----
"Dalton, Barnaby" <Bar...@ra...> wrote:
> 
> Is it possible to share (cascade) parts of configuration file. I am
> generating documentation from a number of different 
> directories for which
> the only differences are the project name and the 
> source/destination. At the
> moment to make a formatting change I have to apply it all of 
> them in turn.
> 
> Ideally I would be able to include the stuff that doesn't 
> change in one file
> and include this in the actual configuration files.

[Doxygen-users] Doc bug for operator %= (), doxygen 1.2.12

[Alexander S. <Ale...@co...>]

Hello all,


it seems that doxygen is not able to produce correct latex output
for the overloaded operator %= .

Minimal sample:
=================================
/// The class X
class X
{
  public:

     /// constructor
     X(void);

     /// overloaded operator
     long operator %= (long n);
}

=================================

The latex output for class X look like this:

\begin{CompactList}\small\item\em constructor.\item\end{CompactList}\item
\hypertarget{classX_a1}{
\index{operator\%=@{operator\%=}!X@{X}}\index{X@{X}!operator%=@{operator\%=}}
long \hyperlink{classX_a1}{operator\%=} (long n)}
\label{classX_a1}

which results in an error compiling with latex:
Runaway argument?
{ \index {operator\%=@{operator\%=}!X@{X}}\index {X@{X}!operatorlong \ETC.
! Paragraph ended before \hypertarget was complete.
<to be read again>
                    \par
l.23


I suppose it should create the following instead
( operator% -> operator\% )

\begin{CompactList}\small\item\em constructor.\item\end{CompactList}\item
\hypertarget{classX_a1}{
\index{operator\%=@{operator\%=}!X@{X}}\index{X@{X}!operator\%=@{operator\%=}}
long \hyperlink{classX_a1}{operator\%=} (long n)}
\label{classX_a1}


Does anyone know how to temporarily prevent this function from being 
commented or how to fix this?


Regards,

	Alexander

Dipl.-Ing. Alexander Speetzen
Communication Networks, Aachen University of Technology;
Phone: ++49-241-8027954, Fax: ++49-241-8022242;
mailto:Ale...@Sp... | mailto:sp...@co...
http://www.speetzen.de,      | http://www.comnets.rwth-aachen.de/~spee

[Doxygen-users] sharing bits of a configuration file

[Dalton, B. <Bar...@ra...>]

Is it possible to share (cascade) parts of configuration file. I am
generating documentation from a number of different directories for which
the only differences are the project name and the source/destination. At the
moment to make a formatting change I have to apply it all of them in turn.

Ideally I would be able to include the stuff that doesn't change in one file
and include this in the actual configuration files.

thanks
Barney


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
pos...@ra....

This footnote also confirms that this email message has been scanned
for the presence of computer viruses known at the time of sending.

www.radioscape.com
**********************************************************************

[Doxygen-users] Package information in Java

[Guillaume H. <Gui...@cg...>]

Hello,

when i use javadoc to produce my code documentation, javadoc use the
package.html files to generate documention on packages. Javadoc has also
the -group flag to group packages in the package page.
Is it possible to have the same feature with Doxygen?

Thanks for your help,

Guillaume Helle

[Doxygen-users] (no subject)

[chen b. <ch...@ya...>]

aGmjug0Kd2hlbiBJIHNlbGVjdCBKYXBhbmFzZSBpbiB0aGUgbGFuZ3VhZ2Ugb3B0aW9uLCBJIGNh
biBub3QgZ2V0IHJlYWRhYmxlDQpydGYoIHJlYWQgYnkgd29yZDIwMDAsIGF0IHdpbjIwMDAgcHJv
KQ0K

RE: [Doxygen-users] Position of & and *.

[<mu...@t-...>]

On Tue, 2002-01-08 at 07:27, Prikryl,Petr wrote:
> Hi,
> 
> I do not think that this is configurable.  The problem is that
> this is not prescribed by the C/C++.  There are reasons
> to format the & and * this way -- it is a matter of formating
> style, not of the functionality.

Of course it is. I'm not saying that this is a bug, but a kack of
functionality.

> Another reason: While e.g. LaTeX is capable of nearly perfect
> typesetting, rendering of HTML documents by various browsers
> requires some tradeoffs.  It is not easy to reach a good look
> of the generated pages.

HTML is perfectly capable of presenting both
sometype* variable;
and
sometype *variable;

I'll try to submit a patch.

[Doxygen-users] Info on the status of the language translators (January 2002)

[Prikryl,Petr <PRI...@sk...>]

(January 8, 2002; zipped translator_report.txt attached)

Hallo to the language maintainers,

Firstly, I wish to all of you all the best in the New
Year.  You know, what are the things that would made
you happy.  Let's your good dreams come true.

My explicit thanks to all language maintainer who gave
their time for free to many many users.  My thanks to
the users who helped to improve doxygen.


Secondly,

   ----------------------------------------------------
   We are searching for Finnish and Swedish maintainers
   because their translators became extremely obsolete.
   Read the text below.
   ----------------------------------------------------

(This is the main reason why this message is posted
also to the "doxygen users" mailing list.)

Now, I am sending this as a reminder of status of the
translator classes for the supported languages (files
translator_xx.h).  No new translator methods were added
to the Translator class since doxygen 1.2.11.  Still,
there are things to improve.

Yesterday, I have updated the doxygen/doc/translator.pl
script that can help you with updating your TranslatorXxx class. 
The script and one of its results, the translator report, can be
found inside the zip fila attached to this message.

The translator report is generated automatically from
sources.  Because of this, it cannot capture human-like
recognition power.  On the other hand, the information
generated by the script should be quite accurate (or
accurately false -- tell me if you find some problem).

The last version of the translator report contains also
the following part:

----------------------------------------------------------------------
The following translator adapter classes are implemented -- the older (with
lower number) are always derived from the newer. They implement the
listed required methods. Notice that some versions of doxygen did not
introduce any changes related to the language translators.  From here you
may
guess how much work should be done to update your translator:
      
  TranslatorAdapter_1_2_11	implements  1 required method...
    QCString trReferences()

  TranslatorAdapter_1_2_7	implements  1 required method...
    QCString trAuthor(bool first_capital, bool singular)

  TranslatorAdapter_1_2_6	implements 13 required methods...
    QCString trRTFansicp()
    QCString trRTFCharSet()
    QCString trRTFGeneralIndex()
    QCString trFile(bool first_capital, bool singular)
    QCString latexLanguageSupportCommand()
    QCString idLanguageCharset()
    QCString trClass(bool first_capital, bool singular)
    QCString trNamespace(bool first_capital, bool singular)
    QCString trGroup(bool first_capital, bool singular)
    QCString trPage(bool first_capital, bool singular)
    QCString trMember(bool first_capital, bool singular)
    QCString trField(bool first_capital, bool singular)
    QCString trGlobal(bool first_capital, bool singular)

  TranslatorAdapter_1_2_5	implements  2 required methods...
    QCString trBug()
    QCString trBugList()

  TranslatorAdapter_1_2_4	implements  8 required methods...
    QCString trInterfaces()
    QCString trClasses()
    QCString trPackage(const char *name)
    QCString trPackageList()
    QCString trPackageListDescription()
    QCString trPackages()
    QCString trPackageDocumentation()
    QCString trDefineValue()

  TranslatorAdapter_1_2_2	implements  2 required methods...
    QCString trProperties()
    QCString trPropertyDocumentation()

  TranslatorAdapter_1_2_1	implements  1 required method...
    QCString trDCOPMethods()

----------------------------------------------------------------------

It clearly shows that it should not be very time
consuming to update the languages at least to the 1.2.4
status (4 of 25 languages).  

It also clearly shows that translators with status
1.2.7 and 1.2.11 can easily be updated to the
up-to-date status (5 languages).

The "Internalization" or "langhowto" part of the
documentation will be updated to match the
translator.pl improvements.

The main problem are the Finnish and Swedish
translators.  It seems that the maintainers are
unreachable.  Their translator classes are very
obsolete.  This will probably cause complication with
near future development.  In the worst case, the
languages may be removed from doxygen.

You can find the zipped translator_report.txt
attached to this message.  The content basically says 
what methods are to be implemented and what methods
should be removed (never used).

 <<tr200201.zip>> 
Here is the snippet from inside that lists the up-to-date
translators.

----------------------------------------------------------------------
The following translator classes are up-to-date (sorted alphabetically).
This means that they derive from the Translator class.  Anyway, there still
may be some details listed even for the up-to-date translators.
Please, check the text below if the translator is marked so.

  TranslatorBrazilian
  TranslatorCroatian
  TranslatorCzech
  TranslatorDutch
  TranslatorEnglish
  TranslatorFrench
  TranslatorGerman
  TranslatorItalian
  TranslatorJapanese    -- see details below in the report
  TranslatorKorean
  TranslatorPortuguese
  TranslatorRussian     -- see details below in the report
  TranslatorSlovak
  TranslatorSlovene

----------------------------------------------------------------------

It show that we have more up-to-date translators again.
Thanks to those, who updated.

The "see details below in the report" generally means
that there are probably some obsolete methods that
should be removed -- they are never used.  

Here the Russian is the exception, because it
implements some new, experimental methods, that were
recognized by the non-thinking script as obsolete (they
are not found in the abstract Translator class in
translator.h).  Read doxygen/html/langhowto.html (the
part of doxygen documentation) for details.

The "should be removed" methods are shown also for
obsolete translators.  In other words, removing
obsolete methods is the easiest way to make things
moving forward ;-)

Thanks for your attention,
  Petr
-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)

[Doxygen-users] Compile problems on solaris

[Alexander L. <li...@we...>]

Hello,

i tried to compile doxygen on solaris 5.6 with SUN Workshop Compiler
5.0  and
got some errors concerning unresolved symbols:

---
...
gmake[1]: Entering directory
`/usr58_13/casiv/tools/doxygen-1.2.11.1/src'
CC -c -O2 -I../qtools -I. -o ../objects/main.o main.cpp
CC  -o ../bin/doxygen ../objects/main.o  -L../lib -ldoxygen -ldoxycfg
-lqtools  -Bdynamic
Undefined                       first referenced
 symbol                             in file
void QDict<MemberDef>::deleteItem(void*) ../lib/libdoxygen.so
void QList<EdgeInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QList<OutputGenerator>::deleteItem(void*) ../lib/libdoxygen.so
void QList<QCString>::deleteItem(void*) ../lib/libdoxygen.so
void QList<IncludeInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QList<IndexField>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<DotNode>::deleteItem(void*) ../lib/libdoxygen.so
void QList<DotNode>::deleteItem(void*) ../lib/libdoxygen.so
void QList<PageInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<ConfigOption>::deleteItem(void*) ../lib/libdoxygen.so
void QList<TagFileInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<CodeClassDef>::deleteItem(void*) ../lib/libdoxygen.so
void QIntDict<MemberDef>::deleteItem(void*) ../lib/libdoxygen.so
void QList<FileName>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<TagFileParser::StartElementHandler>::deleteItem(void*)
../lib/libdoxygen.so
void QDict<IncludeInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<Entry>::deleteItem(void*) ../lib/libdoxygen.so
void QList<TagPackageInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QList<Grouping>::deleteItem(void*) ../lib/libdoxygen.so
void QList<Formula>::deleteItem(void*) ../lib/libdoxygen.so
void QIntDict<QCString>::deleteItem(void*) ../lib/libdoxygen.so
void QList<MemberName>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<ClassDef>::deleteItem(void*) ../lib/libdoxygen.so
void QList<FileDef>::deleteItem(void*) ../lib/libdoxygen.so
void QList<MemberDef>::deleteItem(void*) ../lib/libdoxygen.so
void QIntDict<MemberGroup>::deleteItem(void*) ../lib/libdoxygen.so
void QList<DiagramRow>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<int>::deleteItem(void*)  ../lib/libdoxygen.so
void QList<MemberGroup>::deleteItem(void*) ../lib/libdoxygen.so
void QIntDict<Definition>::deleteItem(void*) ../lib/libdoxygen.so
void QList<TagClassInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QList<GroupDef>::deleteItem(void*) ../lib/libdoxygen.so
void QList<BaseInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QList<Argument>::deleteItem(void*) ../lib/libdoxygen.so
void QList<DocRef>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<Formula>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<QCString>::deleteItem(void*) ../lib/libdoxygen.so
void QList<PackageDef>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<Definition>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<MemberNameInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<DocRef>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<UsesClassDef>::deleteItem(void*) ../lib/libdoxygen.so
void QList<QString>::deleteItem(void*) ../lib/libdoxygen.so
void QList<QGDictIterator>::deleteItem(void*) ../lib/libqtools.so
void QDict<FileName>::deleteItem(void*) ../lib/libdoxygen.so
void QList<Definition>::deleteItem(void*) ../lib/libdoxygen.so
void QList<char>::deleteItem(void*)  ../lib/libdoxygen.so
void QList<BaseClassDef>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<PageInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QList<Example>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<NamespaceDef>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<TagFileParser::EndElementHandler>::deleteItem(void*)
../lib/libdoxygen.so
void QList<int>::deleteItem(void*)  ../lib/libdoxygen.so
void QList<FileList>::deleteItem(void*) ../lib/libdoxygen.so
void QList<TableElem>::deleteItem(void*) ../lib/libdoxygen.so
void QList<NamespaceDef>::deleteItem(void*) ../lib/libdoxygen.so
void QList<TagPageInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QList<QTextCodec>::deleteItem(void*) ../lib/libqtools.so
void QList<ArgumentList>::deleteItem(void*) ../lib/libdoxygen.so
void QList<QFileInfo>::deleteItem(void*) ../lib/libqtools.so
void QDict<StyleData>::deleteItem(void*) ../lib/libdoxygen.so
void QList<DiagramItem>::deleteItem(void*) ../lib/libdoxygen.so
void QList<MemberInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<Example>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<SectionInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QList<TagMemberInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QList<ConfigOption>::deleteItem(void*) ../lib/libdoxygen.so
void QList<CodeVarDef>::deleteItem(void*) ../lib/libdoxygen.so
void QIntDict<RefItem>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<PackageDef>::deleteItem(void*) ../lib/libdoxygen.so
void QIntDict<DocRef>::deleteItem(void*) ../lib/libdoxygen.so
void QList<Entry>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<IndexField>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<void>::deleteItem(void*)  ../lib/libdoxygen.so
void QDict<Define>::deleteItem(void*) ../lib/libdoxygen.so
void QList<ClassDef>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<FileList>::deleteItem(void*) ../lib/libdoxygen.so
void QList<TagGroupInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<MemberName>::deleteItem(void*) ../lib/libdoxygen.so
void QList<SuffixNode>::deleteItem(void*) ../lib/libdoxygen.so
void QList<TagNamespaceInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QList<MemberNameInfo>::deleteItem(void*) ../lib/libdoxygen.so
void QDict<GroupDef>::deleteItem(void*) ../lib/libdoxygen.so
ld: fatal: Symbol referencing errors. No output written to
../bin/doxygen
gmake[1]: *** [../bin/doxygen] Error 1
gmake[1]: Leaving directory `/usr58_13/casiv/tools/doxygen-1.2.11.1/src'

gmake: *** [all] Error 2
gmake: Leaving directory `/usr58_13/casiv/tools/doxygen-1.2.11.1/src'
*** Error code 2
make: Fatal error: Command failed for target `all'
---

I browsed the archives and found one identical questions but no solution
to it. Does anybody has a hint
for me.

Thanks a lot


Alex

[Doxygen-users] Problem with namespaces and templates

[<Car...@no...>]

Hi,

I think I found a problem in Doxygen related to the matching between a
functions's declaration and it's definition, when namespaces and
templates are used:

Consider this code:

-------------------------------------------------
/** \file
Doxygen test with namespaces - implementation
*/

#include <vector>

void f(std::vector<int>* pVector);

using std::vector;

/// example function
void f(vector<int>* pVector) {
}

/// main function
int main(const int argc, const char* const argv[]) {
  vector<int> v;
  f(&v);
  return 0;
}
-------------------------------------------------

When I run Doxygen with a plain-vanilla Doxyfile (with QUIET=YES) I get
these warnings:

/home/carloshe/doxygenProblem/namespaces.cc:7 Warning: Member f of file
namespaces.cc is not documented.


If I change the definition of function f to:

void f(std::vector<int>* pVector)

Then I don't get any problem.


I have not seen this happen with similar cases where the definition was
less qualified then the declaration but templates were not involving so
this might be related to some interaction between namespaces and
templates when matching function signatures.

Regards,
Carlos

RE: [Doxygen-users] 3 feature requests

[Kremer, A. <ale...@in...>]

Hi all,

I have a related question maybe a feature enhancement,
I'd like to implement myself, but I need some pointer.

\bug, \todo, etc. cannot appear within the function
body (implementation). I would be nice to be able to put
a \bug report or a \todo on the exact spot in the
code where it happens.

When I tried to do it, I got a reference to
a function/method/variable/... following the body.
 and not the current one.
(if it is the last function it ignores it completely)

Example:

f() {
	//some code
	/** \bug the following is some buggy code */
	//some buggy code
	...
}

g() { // function that follows f()
=09
}

The actual \bug will be referring g() and not f().

Can anyone familiar with the Doxygen code point me
on how to solve this. It would be a very nice feature
for code-reviewing if you could just annotate the problematic
code within the body and get a nice reference list
that pinpoints all the problems...

kreso


| -----Original Message-----
| From: Cyrille Ch=E9p=E9lov [mailto:cy...@so...]
| Sent: Mon, January 07, 2002 12:18 PM
| To: dox...@li...
| Subject: [Doxygen-users] 3 feature requests
|=20
|=20
| Hi all, and thanks for the wonderful tool...
|=20
| I would love to see three features:
|=20
|     1) Ability to define new tags like \todo and \test, in=20
| the doxygen.cfg,
| like \security (eg. to leave out notes about areas to=20
| re-audit). Ideally,
| whenever such administrator-defined tags are encountered, the=20
| text would be
| accumulated to a
| new page (also defined in the doxygen.cfg) and shown on the =
"associate
| pages" list.
|=20
|     2) Ability to limit the depth of collaboration graphs, by=20
| access type.
| Let's say I've got this:
|=20
| class VeryCommonHelper {
|    /* a dense forest of otherwise trivial attributes */
| };
|=20
| class SomeClass {
|    VeryCommonHelper& a_helper;
|    char          a_other;
|    AnotherClass  a_stuff;
| };
|=20
| I would like the ability to not display what's in=20
| VeryCommonHelper, unless
| I'm looking at VeryCommonHelper's collab graph. OTOH, I may=20
| be interested in
| having AnotherClass' graph be expanded in SomeClass' graph.=20
| Could it be done
| by a \tag in VeryCommonHelper's docstring ? Like an array of=20
| options like
| \hide${i}InDeepGraph (with i in "Private", "Protected",=20
| "Public", "Base",
| "All").
|=20
|     3) Nicer handling of template instanciations
|=20
| I've got a template class which looks a lot like ATL's CPtr:
| template<class T> class smptr { ... };
|=20
| it is used that way:
| typedef smptr<SomeClass> p_SomeClass;
|=20
| and then each time a smart pointer to SomeClass is needed,=20
| p_SomeClass is
| used.
|=20
| Problem is, if I look at the collab graph of :
|=20
| class SomeClassUser {
|   p_SomeClass a_sc;
| };
|=20
| I see this:
|         [smptr< SomeClass >]
|                ^
|                |
|         [SomeClassUser]
| which is fine.
|=20
| Now, when I click on smptr< SomeClass >, I get the collab=20
| graph of smptr< T
| >, which is fine but makes collab graph navigability harder.
|=20
| It would be extremely nice if there was YACO, which forced=20
| the construction
| of an intermediary "template instanciation" page, which would=20
| say (in the
| above case):
|    <h1>Template Instanciation Reference</h1>
|    Template class: smptr
|    Template argument T: SomeClass
|=20
| .. with of course, the relevant links. This'd be very sweet=20
| (even sweeter
| would be the ability to have the words "smptr" and=20
| "SomeClass" in the above
| collab graph link each to its page, but that is maybe a=20
| little too much to
| ask from GraphViz).
|=20
|=20
|=20
| Thanks a lot in advance !
|=20
|     -- Cyrille
|=20
|=20
|=20
| _______________________________________________
| Doxygen-users mailing list
| Dox...@li...
| https://lists.sourceforge.net/lists/listinfo/doxygen-users
|=20

[Doxygen-users] 3 feature requests

[<cy...@so...>]

Hi all, and thanks for the wonderful tool...

I would love to see three features:

    1) Ability to define new tags like \todo and \test, in the doxygen.cfg,
like \security (eg. to leave out notes about areas to re-audit). Ideally,
whenever such administrator-defined tags are encountered, the text would be
accumulated to a
new page (also defined in the doxygen.cfg) and shown on the "associate
pages" list.

    2) Ability to limit the depth of collaboration graphs, by access type.
Let's say I've got this:

class VeryCommonHelper {
   /* a dense forest of otherwise trivial attributes */
};

class SomeClass {
   VeryCommonHelper& a_helper;
   char          a_other;
   AnotherClass  a_stuff;
};

I would like the ability to not display what's in VeryCommonHelper, unless
I'm looking at VeryCommonHelper's collab graph. OTOH, I may be interested in
having AnotherClass' graph be expanded in SomeClass' graph. Could it be done
by a \tag in VeryCommonHelper's docstring ? Like an array of options like
\hide${i}InDeepGraph (with i in "Private", "Protected", "Public", "Base",
"All").

    3) Nicer handling of template instanciations

I've got a template class which looks a lot like ATL's CPtr:
template<class T> class smptr { ... };

it is used that way:
typedef smptr<SomeClass> p_SomeClass;

and then each time a smart pointer to SomeClass is needed, p_SomeClass is
used.

Problem is, if I look at the collab graph of :

class SomeClassUser {
  p_SomeClass a_sc;
};

I see this:
        [smptr< SomeClass >]
               ^
               |
        [SomeClassUser]
which is fine.

Now, when I click on smptr< SomeClass >, I get the collab graph of smptr< T
>, which is fine but makes collab graph navigability harder.

It would be extremely nice if there was YACO, which forced the construction
of an intermediary "template instanciation" page, which would say (in the
above case):
   <h1>Template Instanciation Reference</h1>
   Template class: smptr
   Template argument T: SomeClass

.. with of course, the relevant links. This'd be very sweet (even sweeter
would be the ability to have the words "smptr" and "SomeClass" in the above
collab graph link each to its page, but that is maybe a little too much to
ask from GraphViz).



Thanks a lot in advance !

    -- Cyrille

Re: [Doxygen-users] Inconsistency of FILE_PATTERNS

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

On Sun, Jan 06, 2002 at 12:09:41AM +0800, Jerzy Kaczorowski wrote:
> I use doxygen 1.2.13.1 on w2k prof. There seem to be a small inconsistency
> around the FILE_PATTERNS setting.
> 
> 1. Problem one: In the config file in the description of the setting there
> is a list of the tested patterns if the setting is left blank. It goes:
> 
> #If left blank the following patterns are tested:
> # *.c *.cc *.cxx *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
> *.hpp
> # *.h++ *.idl
> 
> That list doesn't seem to be complete. For example it doesn't list the
> *.cpp, yet that pattern is tested and the files with .cpp extension are
> properly documented. It would be nice to have a complete list of the tested
> patterns thought since that contributes to the decision whether to leave the
> setting blank or to actually fill it in.
> 
> In the documentation however, it states:
> FILE_PATTERNS
> If the value of the INPUT tag contains directories, you can use the
> FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
> *.h ) to filter out the source-files in the directories. If left blank all
> files are included (i.e. wildcard *).
> 
> Where it says that all files are included, that is not correct also...

I'll correct these inconsistencies.

> 
> 2. Problem two: While at it - it would be just great if the default pattern
> also contained the *.odl file pattern together with already present *.idl.

I'll add it.

> If that was the case I would not have to list all the patterns just to apped
> the .odl files. Alternatively, is there a way append the file patterns to
> the default list instead of ovewriting it? If not, perhaps something like
> that:
> 
> FILE_PATTERNS          = $(FILE_PATTERNS) value [value, ...]

Normally += can be used for this. But the way it is implemented now, the
default patterns are added afterwards, and only if the FILE_PATTERNS tag 
is empty, so this wouldn't work.

Regards,  
  Dimitri

[Doxygen-users] Inconsistency of FILE_PATTERNS

[Jerzy K. <je...@wn...>]

I use doxygen 1.2.13.1 on w2k prof. There seem to be a small inconsistency
around the FILE_PATTERNS setting.

1. Problem one: In the config file in the description of the setting there
is a list of the tested patterns if the setting is left blank. It goes:

#If left blank the following patterns are tested:
# *.c *.cc *.cxx *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
*.hpp
# *.h++ *.idl

That list doesn't seem to be complete. For example it doesn't list the
*.cpp, yet that pattern is tested and the files with .cpp extension are
properly documented. It would be nice to have a complete list of the tested
patterns thought since that contributes to the decision whether to leave the
setting blank or to actually fill it in.

In the documentation however, it states:
FILE_PATTERNS
If the value of the INPUT tag contains directories, you can use the
FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
*.h ) to filter out the source-files in the directories. If left blank all
files are included (i.e. wildcard *).

Where it says that all files are included, that is not correct also...

2. Problem two: While at it - it would be just great if the default pattern
also contained the *.odl file pattern together with already present *.idl.
If that was the case I would not have to list all the patterns just to apped
the .odl files. Alternatively, is there a way append the file patterns to
the default list instead of ovewriting it? If not, perhaps something like
that:

FILE_PATTERNS          = $(FILE_PATTERNS) value [value, ...]

Where $(FILE_PATTERNS) would be a variable defined internally by doxygen for
the default settings.

Thanks and Best Regards,
Jerzy

[Doxygen-users] Doxygen-1.2.13.1 in CVS

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

Hi,

Due to some problems in the previous release, I decided to put out a new one, 
with the following changelog:
----------------------------------------------------------------------------
+ BUG: Links to grouped members were broken.
+ BUG: The Module index was broken in HTML and subgroups were still not
       sorted properly.
+ BUG: Selecting a non-default language was not possible in doxywizard
       (thanks to Heiko Schaefer for the patch).
+ BUG: Ending a dash-style list was not possible by starting a new paragraph
       anymore.
+ BUG: Fixed "exceptions" tag mismatch in the XML output.
+ BUG: extern "C" blocks inside source files incorrectly included header files
       during preprocessing.
+ BUG: Compiling doxywizard on Unix with Qt-3.x didn't work because
       doxycfg was linked with qtools from Qt-2.x.
+ BUG: Fixed potential memory corruption when generation the graphical class
       hierarchy (nodes were deleted more than once).
+ ADD: Added support for multi-method declarations such as: int func1(),func2();
+ ADD: Included updated DTD for validating the XML output produced by doxygen,
       thanks to Angelo Hulshout.
+ ADD: Included support for Japanese-ShiftJIS translation,
       thanks to Ryunosuke Sato.
+ ADD: Included update for Slovak translator, thanks to Stanislav Kudlac.
+ ADD: Thanks to a patch by Pascal Flammant tables in the documentation
       can now have captions using <caption> ... </caption> within a
       table definition.
+ ADD: A dash-style list can now be ended without ending the paragraph.
       See the list-section of the documentation for an example.
----------------------------------------------------------------------------
Enjoy,
  Dimitri

FW: [Doxygen-users] RE including headerfiles inside extern "C"

[Catenacci, O. <Ono...@co...>]

I've also seen an #ifdef __cplusplus__ used for this same purpose.

The advantage of doing this in the header is that it's better information
hiding.  This way, your user can include your file.h without having to worry
about putting the extern "C" declaration around it if it's used in C++
source.

-- 
Onorio

> -----Original Message-----
> From: Clift Norris [mailto:no...@ac...] 
> Sent: Friday, January 04, 2002 8:44 AM
> To: dox...@li...
> Subject: [Doxygen-users] RE including headerfiles inside extern "C"
> 
> 
> 
> 
> 
> You could do it this way (in the C header file):
> 
> #ifndef __STDC__
> extern "C"
> {
> #endif
> 
>    // code that is "C" language only
> 
> #ifndef __STDC__
> }  // close for extern "C"
> #endif
> 
> 
> -Clift
> 
> 
> 
> -----Original Message-----
> From: dox...@li...
> [mailto:dox...@li...]On Behalf 
> Of Tommy Sanddal
> Poulsen
> Sent: Friday, January 04, 2002 6:33 AM
> To: 'dox...@li...'
> Subject: [Doxygen-users] RE: including headerfiles inside extern "C"
> 
> 
> The reason for not having the extern "C" declaration inside 
> the file.h is
> that the file.h is considered a standard C header file and is 
> heavily used
> in standard C programs on several platforms and compilers.
> The problem only appears for #defines - not for e.g. typedefs etc.
> -----Original Message-----
> FROM: Catenacci, Onorio
> DATE: 01/04/2002 03:41:10
> SUBJECT: FW: [Doxygen-users] including headerfiles inside extern "C"
> Is there anything preventing you from moving the extern "C" 
> declaration to
> the file.h file?  Something like this:
> 
> file.h:
> /// MEDEF doc
> extern "C" {
>    #define MYDEF 1
> 
> //etc.
> 
> } //end extern "C" declaration
> 
> fileA.cpp
> #include "file.h" //automatically picks up extern "C" because 
> it's in the
> header file.
> 
> In fact I'm more accustomed to seeing the extern "C" in the 
> header file as
> opposed to being in the files that include the header.  Of course that
> doesn't mean that is more correct--it's just what I'm 
> accustomed to seeing.
> 
> --
> Onorio Catenacci
> -----Original Message-----
> From: Tommy Sanddal Poulsen [mailto:<EMAIL: PROTECTED>]
> Sent: Friday, January 04, 2002 4:42 AM
> To: '<EMAIL: PROTECTED>'
> Subject: [Doxygen-users] including headerfiles inside extern "C"
> 
> 
> 
> Hi,
> I'm currently working on a project implemented in C++ and 
> having C interface
> functions declared in separate h-files. The header files are 
> included inside
> extern "C" blocks, and this results in multiple define 
> documentation blocks
> in the doxygen documentation for the h-file.
> The three files file.h, fileA.cpp and fileB.cpp documented 
> using a standard
> doxygen config file (although EXTRACT_ALL=YES) yields the 
> peculiar result of
> three blocks documenting the define of the headerfile - I 
> expected only one,
> as is the result when the #include's are not embedded inside 
> an extern "C"
> block.
> Does anyone have an idea of what to do ?
> file.h:
>         /// MEDEF doc
>         #define MYDEF 1
> fileA.cpp
>         extern "C" {
>           #include "file.h"
>         }
>         void fA() {}
> fileB.cpp
>         extern "C" {
>           #include "file.h"
>         }
>         void fB() {}
> 
> 
> - thanks
> >Tommy Poulsen
> 
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 

[Doxygen-users] RE including headerfiles inside extern "C"

[Clift N. <no...@ac...>]

You could do it this way (in the C header file):

#ifndef __STDC__
extern "C"
{
#endif

   // code that is "C" language only

#ifndef __STDC__
}  // close for extern "C"
#endif


-Clift



-----Original Message-----
From: dox...@li...
[mailto:dox...@li...]On Behalf Of Tommy Sanddal
Poulsen
Sent: Friday, January 04, 2002 6:33 AM
To: 'dox...@li...'
Subject: [Doxygen-users] RE: including headerfiles inside extern "C"


The reason for not having the extern "C" declaration inside the file.h is
that the file.h is considered a standard C header file and is heavily used
in standard C programs on several platforms and compilers.
The problem only appears for #defines - not for e.g. typedefs etc.
-----Original Message-----
FROM: Catenacci, Onorio
DATE: 01/04/2002 03:41:10
SUBJECT: FW: [Doxygen-users] including headerfiles inside extern "C"
Is there anything preventing you from moving the extern "C" declaration to
the file.h file?  Something like this:

file.h:
/// MEDEF doc
extern "C" {
   #define MYDEF 1

//etc.

} //end extern "C" declaration

fileA.cpp
#include "file.h" //automatically picks up extern "C" because it's in the
header file.

In fact I'm more accustomed to seeing the extern "C" in the header file as
opposed to being in the files that include the header.  Of course that
doesn't mean that is more correct--it's just what I'm accustomed to seeing.

--
Onorio Catenacci
-----Original Message-----
From: Tommy Sanddal Poulsen [mailto:<EMAIL: PROTECTED>]
Sent: Friday, January 04, 2002 4:42 AM
To: '<EMAIL: PROTECTED>'
Subject: [Doxygen-users] including headerfiles inside extern "C"



Hi,
I'm currently working on a project implemented in C++ and having C interface
functions declared in separate h-files. The header files are included inside
extern "C" blocks, and this results in multiple define documentation blocks
in the doxygen documentation for the h-file.
The three files file.h, fileA.cpp and fileB.cpp documented using a standard
doxygen config file (although EXTRACT_ALL=YES) yields the peculiar result of
three blocks documenting the define of the headerfile - I expected only one,
as is the result when the #include's are not embedded inside an extern "C"
block.
Does anyone have an idea of what to do ?
file.h:
        /// MEDEF doc
        #define MYDEF 1
fileA.cpp
        extern "C" {
          #include "file.h"
        }
        void fA() {}
fileB.cpp
        extern "C" {
          #include "file.h"
        }
        void fB() {}


- thanks
>Tommy Poulsen

[Doxygen-users] RE: including headerfiles inside extern "C"

[Tommy S. P. <TS...@ma...>]

The reason for not having the extern "C" declaration inside the file.h is
that the file.h is considered a standard C header file and is heavily used
in standard C programs on several platforms and compilers.
The problem only appears for #defines - not for e.g. typedefs etc. 

-----Original Message-----
FROM: Catenacci, Onorio
DATE: 01/04/2002 03:41:10
SUBJECT: FW: [Doxygen-users] including headerfiles inside extern "C"
Is there anything preventing you from moving the extern "C" declaration to
the file.h file?  Something like this:
 
file.h: 
/// MEDEF doc
extern "C" {
   #define MYDEF 1
 
//etc.
 
} //end extern "C" declaration
 
fileA.cpp
#include "file.h" //automatically picks up extern "C" because it's in the
header file.
 
In fact I'm more accustomed to seeing the extern "C" in the header file as
opposed to being in the files that include the header.  Of course that
doesn't mean that is more correct--it's just what I'm accustomed to seeing.
 
-- 
Onorio Catenacci

-----Original Message-----
From: Tommy Sanddal Poulsen [mailto:<EMAIL: PROTECTED>] 
Sent: Friday, January 04, 2002 4:42 AM
To: '<EMAIL: PROTECTED>'
Subject: [Doxygen-users] including headerfiles inside extern "C"



Hi, 
I'm currently working on a project implemented in C++ and having C interface
functions declared in separate h-files. The header files are included inside
extern "C" blocks, and this results in multiple define documentation blocks
in the doxygen documentation for the h-file.

The three files file.h, fileA.cpp and fileB.cpp documented using a standard
doxygen config file (although EXTRACT_ALL=YES) yields the peculiar result of
three blocks documenting the define of the headerfile - I expected only one,
as is the result when the #include's are not embedded inside an extern "C"
block. 

Does anyone have an idea of what to do ? 

file.h: 
        /// MEDEF doc 
        #define MYDEF 1 

fileA.cpp 
        extern "C" { 
          #include "file.h" 
        } 

        void fA() {} 

fileB.cpp 
        extern "C" { 
          #include "file.h" 
        } 

        void fB() {} 


- thanks 
>Tommy Poulsen