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

[Doxygen-develop] Handling of #include directive broken

[Enrico S. <enr...@in...>]

Hello,

when having a directory tree like

|  .
|  |-- Doxyfile
|  `-- x
|      |-- 1.h
|      |-- 2.h
|      `-- test.cc

with

| $ cat x/test.cc  
| #include "1.h"
| BAD
|
| $ cat x/1.h 
| #include "2.h"
|
| $ cat x/2.h 
| #define BAD     GOOD
|
| $ cat Doxyfile 
| INPUT = x/test.cc
| MACRO_EXPANSION = yes
| QUIET = YES


I get

| $ doxygen -d Processor
| 00002 BAD
| 00003


Using gcc results in

| $ gcc -E x/test.cc 
| # 1 "x/test.cc"
| # 1 "<built-in>"
| # 1 "<command line>"
| # 1 "x/test.cc"
| # 1 "x/1.h" 1
| # 1 "x/2.h" 1
| # 2 "x/1.h" 2
| # 2 "x/test.cc" 2
| GOOD


Strace'ing doxygen shows that it searches at the wrong places for '2.h':

| access("x/test.cc", R_OK)               = 0
| open("/tmp/dox/x/test.cc", O_RDONLY) = 3
| access("/tmp/dox/x//1.h", F_OK)      = 0
| open("/tmp/dox/x//1.h", O_RDONLY)    = 4
| access("/tmp/dox/2.h", F_OK)         = -1 ENOENT (No such file or directory)




Enrico

[Doxygen-develop] C++ parser

[Philippe F. <P....@OB...>]

	Hi,

I want to write a Refactor tool and I am looking for a C++ parser. I
remember once someone showing me that Doxygen could generate a XML file
representing the C++ code. What I need is a something able to parse C++ ant
give a structure where I know what classes, functions, variables, defines,
signal and slots are defined, and where in the source code. Do you think
Doxygen could be used to do that ?

	regards,

	Philippe

[Doxygen-develop] [Fwd: Fwd: Doxygen :pour langage ADA et VHDL]

[Xavier O. <xav...@an...>]

Hi,

FYI.

Sorry it's a mail in French.
Someone looking for Doxygen for ADA and VHDL to
gererate HTML.

Greetings,

Xavier.
--
 D2SET Scientific and Technical Non profit Association
  http://www.d2set.org/
  mailto:d2...@d2...

 Artificial Anthill Project
  http://www.aanthill.org/
  mailto:aan...@aa...

Michel Violette wrote:
> Monsieur,
>=20
> Est-il pr=E9vu un d=E9veloppement de DOXYGEN pour les langages ADA et V=
HDL?
> Si non connaissez vous un outil qui permet de g=E9n=E8rer de la doc HTM=
L dans ces
> langages?
>=20
> En vous remerciant,
> Salutations
>=20
> Michel Violette
> Soci=E9t=E9 Faiveley
> ZI du bois de plante
> 37700 La Ville aux Dames

[Doxygen-develop] cross references

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

Hi

I would like to request Feature/ bug fix in cross referencing.

Multiple definitions of one function within one project seems to confuse 
the doxygen.
For example the project contains main program and few testing programs.
All af those have the function main, but the references to main tend to 
point to only one of them.

(I'm using 1.2.14)

Doxygen would benefit from having references to functions bound also to 
the name of the source file.

If the reference is kept only to the functions, the file names can be 
kept in container attached to the function object.
References  can resolved afterwards trough includes or not resolved at 
all given all possible references in the place.


I looked  again and see that the inconsistency in references is true 
only for the anchors (weblinks) in the source code pages.
The 'main' in source code page of one file takes me to the documentation 
page of the different file.

Keep up the good work.

Jan

[Doxygen-develop] help can't read input-file

[Jean-Luc N. <Jea...@st...>]

Hello I have just installed doxygen,
but I can't read my input file I get this error messages

D:\DOXYGEN\bin>doxygen Toldskat
Searching for include files...
Searching for example files...
Searching for images...
Searching for dot files...
Searching for files to exclude
Reading input files...
No input read, no output generated!

and here is my  INPUT            ="D:/toldskat106/source" source is where I
have the source code.
please help

[Doxygen-develop] How hard would it be to add support for managed C++ ?

[Philippe L. <phi...@ca...>]

Hi

Visual .NET introduces managed C++. It simplifies a lot of stuff for =
handling IDL and other nice little technologies like that.

The format is as follows

// IMerchant
[
	object,
	uuid("C158C40C-732A-46BA-8A01-F5D901D6E1D8"),
	dual,	helpstring("IMerchant Interface"),
	pointer_default(unique)
]
__interface IMerchant : IDispatch
{
	[propget, id(1), helpstring("property Name")] HRESULT Name([out, =
retval] BSTR* pVal);
	[propput, id(1), helpstring("property Name")] HRESULT Name([in] BSTR =
newVal);
	[id(4), helpstring("method Do")] HRESULT Do([in] BSTR* SomeInput, =
[out,retval] BYTE* result);
};


Basically, Microsoft added attributes inside [] that allow the =
developper to specify some meta-data about the methods (it's a property =
get, a property set, any help string associated with it, etc.).

I'm wondering how hard it would be to add support for managed C++ inside =
doxygen ?

I was going to write a program that would do search and replace inside =
an __interface block, however you seasonned developpers might know a =
better way to integrate this inside doxygen.=20

Any tips on how to proceed are welcomed.

Thanks

Phil

Re: [Doxygen-develop] cannot compile with bison 1.34

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

On Sun, Apr 07, 2002 at 10:24:12PM +0900, Sato Ryunosuke wrote:
> Hi,
>=20
> I use doxygen on cygwin,
> I cannot compile doxygen with bison 1.34.
> -----------------------------------------------
> ce_parse.cpp:337: member `class CPPValue yyalloc::yyvs' with constructor=
=20
> not all
> owed in union
> -----------------------------------------------
> Recently cygwin use bison 1.34. I compiled with bison 1.29 on cygwin.=1B$=
B!!=1B(B
>=20
> I want to remove this problem, but I'm ignorant about bison.
> Do you know how to compile doxygen with bison 1.34?
> I confirmed that same problem occurs on linux.

You need to get version 1.35 of bison. All versions in the range 1.30 to 1.=
34
are broken.

Regards,
  Dimitri

[Doxygen-develop] addon\doxmlparser bugs?

[<ca...@Cr...>]

    Is some one interested in errors of addon\doxmlparser\test code?
    I try to parse doxygen xml output format and use doxmlparser. The =
code below is NOT a comment to real program it is tests my parser.
   =20
1. IDocProgramListing interface can contain some text but =
<linenumber>..</linenumber>. The sample below illustrate inaccessible =
text "Simple text" throw IDocProgramListing.
/*! \file
 * <pre>Simple text</pre>
 */
=20
 2. Is the code bellow incorrect?
 /*! \page mypage mypage
 *
 * The text
*
 * <H1>Title</H1>
 */
 and why the code=20
=20
 /*! \page mypage mypage
 * <H1>Title</H1>
 */
&=20
 /*! \page mypage mypage
 *
 * The text
*
 * <H2>Title</H2>
 */
 correct?
=20
3. Doxygen generate invalid xml output for <caption> tag
/*!
 * \page mypage mypage
 * <table><tr><td>Column</td></tr>
* <caption>Caption</caption></table>
*/
  Html output is valid.
=20
4. addon\doxmlparser\test dosn't parse anchors.
 /*! \page mypage mypage
 * <A name=3D"name">text</A>
 */
Doxygen generate valid xml, but there is no <anchor> handler.
=20
    - Alexandr -

[Doxygen-develop] cannot compile with bison 1.34

[Sato R. <su...@ho...>]

Hi,

I use doxygen on cygwin,
I cannot compile doxygen with bison 1.34.
-----------------------------------------------
ce_parse.cpp:337: member `class CPPValue yyalloc::yyvs' with constructor 
not all
owed in union
-----------------------------------------------
Recently cygwin use bison 1.34. I compiled with bison 1.29 on cygwin.　

I want to remove this problem, but I'm ignorant about bison.
Do you know how to compile doxygen with bison 1.34?
I confirmed that same problem occurs on linux.

Ryunosuke Sato
su...@ho...

_________________________________________________________________
メールだけじゃなかった！インターネット便利サービスがひとまとまり 
http://explorer.msn.co.jp/

[Doxygen-develop] Info on the status of the language translators (April 4th, 2002)

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

Info on the status of the language translators (April 4th, 2002)

(Related to the Doxygen-1.2.15 in CVS; full
translator_report.txt included in the attached zip file.

Posted to doxygen-develop [for the language
maintainers], copy posted to doxygen-users [searching
for Finnish and Swedish language maintainers].)

Hi,

  -----------------------------------------------
  We are still searching for Finnish and Swedish
  maintainers because their translators became
  extremely obsolete.  It seems that the original
  maintainers are not in touch with doxygen any more
  (read it "unreachable").
  
  It may happen that Finnish and Swedish translator
  will disappear one day, when more complicated
  changes will be applied to the translator part of
  doxygen sources.
  
  Please, if you know some Finnish or Swedish speaking
  friends (programmers) who could be interested in
  doxygen, try to contact them.
  -----------------------------------------------
  
The attached traslator_report.txt shows the current
status of the Translator classes.  We have 4 more
up-to-date translators since the last "Info..." from
5th February (German, Japanese, Portuguese, and
Romanian).  My special thanks go to the language
maintainers who keep their translators up-to-date.

The interesting fact also is that next 8 translators
are very close to the up-to-date status. It requires
to implement only 4 methods from 1.2.7 level to the
up-to-date.  So, why not to do it now? ;)

I would like to encourage the maintainers of the 
Hungarian, Norwegian, and Polish languages to skip to
at least 1.2.6 level.  This means to implement
1+2+8+2 = 13 methods. Let next leap is from 1.2.6
level to 1.2.7 -- another 13 required methods.

To implement the rest 4 methods to be up-to-date is a
piece of cake.  (... and a lot of users will
applaud to you ;-)

See the excerpt (from the attached translator
report), below.  Notice, that the translator.pl
script now shows also what required methods are
implemented by what translators.

----------------------------------------------------------------------
The following translator classes are up-to-date (sorted alphabetically).
This means that they derive from the Translator class.  [...]

  TranslatorBrazilian
  TranslatorCroatian
  TranslatorCzech
  TranslatorDutch
  TranslatorEnglish
  TranslatorFrench
  TranslatorGerman
  TranslatorItalian
  TranslatorJapanese    (just remove the obsolete trAuthors())
  TranslatorPortuguese
  TranslatorRomanian
  TranslatorRussian

----------------------------------------------------------------------
The following translator classes are obsolete (sorted alphabetically).
This means that they derive from some of the adapter classes.

  TranslatorChinese     (TranslatorAdapter_1_2_13)
  TranslatorDanish      (TranslatorAdapter_1_2_7)
  TranslatorGreek       (TranslatorAdapter_1_2_11)
  TranslatorHungarian   (TranslatorAdapter_1_2_1)
  TranslatorKorean      (TranslatorAdapter_1_2_13)
  TranslatorNorwegian   (TranslatorAdapter_1_2_2)
  TranslatorPolish      (TranslatorAdapter_1_2_1)
  TranslatorSlovak      (TranslatorAdapter_1_2_13)
  TranslatorSlovene     (TranslatorAdapter_1_2_13)
  TranslatorSpanish     (TranslatorAdapter_1_2_7)
  TranslatorUkrainian   (TranslatorAdapter_1_2_11)

----------------------------------------------------------------------
The following translator classes are implemented via deriving
from the English translator.  This should be done only in the case
when the language maintainer or the doxygen developers need to update
some really outdated translator.  Otherwise, deriving from
the translator adapter classes should be prefered for obsolete translators.
See details below in the report.

  TranslatorFinnish     (TranslatorEnglish)
  TranslatorSwedish     (TranslatorEnglish)

----------------------------------------------------------------------
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_13      implements  2 required methods...
    QCString trImplementedFromList(int numEntries)
    QCString trImplementedInList(int numEntries)

  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()

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

Thanks for paying attention, 
  Petr
 <<tr200204.zip>> 
-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)

[Doxygen-develop] Feature request: \prev tag

[Jaap S. <s98...@ho...>]

Hello people,

I have an idea for a new tag in Doxygen. I don't know how hard it would be 
to implement it, or whether you even have time for it. But it would 
certainly be usefull to me.

Every now and then I have a list of flags or attributes that all more or 
less the same comment for them. simple example:

const unsigned long BIT_0 = 1<<0;   //!< Number with only bit 0 set.
const unsigned long BIT_1 = 1<<2;   //!< Number with only bit 1 set.
const unsigned long BIT_2 = 1<<3;   //!< Number with only bit 2 set.
...
const unsigned long BIT_31 = 1<<31;   //!< Number with only bit 31 set.

Apart from the un-usefullness of this example (i've seen better examples, 
but can't think of any now) this copy pasting of comments should be avoided 
ofcourse.

This is already possible in Doxygen by using groups. Just wrap all those 
constants in a (sub-)group and comment that group. Example (can't remember 
the exact syntax here):

/*!
       \defgroup BitDefines
       These constants BIT_N represent numbers
       where only bit N is set.
*/
//!{
const unsigned long BIT_0 = 1<<0;
const unsigned long BIT_1 = 1<<2;
..
const unsigned long BIT_31 = 1<<31;
//!}

However, this is a hassle, and clutters the comments-style if used in 
between loads of other code. What if we could do the following:

const unsigned long BIT_0 = 1<<0;   //!< BIT_N has only bit N set.
const unsigned long BIT_1 = 1<<2;   //!< \prev
const unsigned long BIT_2 = 1<<3;   //!< \prev

etc.

So the previous comment is used for the current comment too.

Mmmmm, now I read this email, this doesn't sound like a very usefull tag. 
However, I can recall some moments during coding where I could have used it.

Ah well, never mind...

Cheers,

Jape











_________________________________________________________________
Meld je aan bij de grootste e-mailservice wereldwijd met MSN Hotmail: 
http://www.hotmail.com/nl

[Doxygen-develop] Bug? Namespace aliases

[Howard K. <hka...@ma...>]

Are there problems with namespace aliases?


I have 2 libraries.

One is equivalent to the Microsoft Platform SDK -- I just use it.
It has a header file (BCC.HPP)
	/**
	 * @namespace BigComputerCorporation
	 * The big namespace blah blah blah 
	 */
	namespace BigComputerCorporation
	{
	...
	}
	/** 
	 * @namespace BCC
	 * Alias for BigComputerCorporation
	 */
	namespace BCC = BigComputerCorporation;
with some files like
	/**
	 * ...doxygen documentation...
	 */
	void BCC::SomeClass::SomeMethod() { ... }
and it has doxygen generated docs.

In my library, I have a header (REMORA.HPP)
	#include <BCC.HPP>
	namespace BigComputerCorporation
	{
	/**
	 * @namespace Remora
	 * A small addition blah blah blah
	 */
	namespace Remora
	{
	/**
	 * Nifty extension blah blah blah
	 */
	class NiftyExtension
	{
		public: static void blah();
	};
	}
	}
and a source file (REMORA.CPP)
	#include <REMORA.HPP>
	/**
	 * My docs that doxygen doesn't include in its output!
	 */
	void BCC::Remora::NiftyExtension::blah() { do_something_cool(); }


When I run Doxygen I see it preprocesses REMORA.HPP and REMORA.CPP, but the
generated docs only have the raw signatures -- blah()'s documentation is
*not* included in the output.

Doxygen also spews a warning message for blah() (and anything else specified
with the BCC namespace alias).


If I add to REMORA.HPP the snippet
	#if defined(DOXYGEN_SHOULD_SKIP_THIS)
	namespace BCC = BigComputerCorporation;
	#endif
then suddenly doxygen generates output with all my doccomments for blah()
and the like.


Why?

The "BCC" namespace alias statements seems to be handled properly if it's in
a file specified in the INPUT/FILE_PATTERNS tag, but if it's just #include'd
by one of the INPUT files then doxygen seems to ignore it (causing
downstream havoc).


Smells like a bug to me.

I've added the hackaround for now, but it seems pretty ugly -- especially as
we plan to break up some monolithic applications into collections of smaller
toolkits/SDKs, and we have some namespace aliases (everything's scoped to a
COMPANY::PROJECT namespace, and we use namespace aliases wherever we can as
the COMPANY and PROJECT names can be annoyingly long; namespace aliases to
the rescue! But doxygen doesn't seem to play nice with the other
children...).

	- Howard

[Doxygen-develop] Patch: Undocumented parammeters / return value warnings.

[Itai F. <ita...@ya...>]

cvs diff doc.h (in directory C:\cvs\src)
Index: doc.h
===================================================================
RCS file: /u/kp3softd/cvsroot/src/doc.h,v
retrieving revision 1.5
diff -r1.5 doc.h
27,29c27,32
<                      const char *fileName,int startLine,
<                      const char *clName, MemberDef *md,
<                      const QCString &docString);
---
>                      const char *fileName,
>                      int startLine,
>                      const char *clName, 
>                      MemberDef *md,
>                      const QCString &docString,
>                      bool detailedDescription = false);

*****CVS exited normally with code 1*****


cvs diff doc.l (in directory C:\cvs\src)
Index: doc.l
===================================================================
RCS file: /u/kp3softd/cvsroot/src/doc.l,v
retrieving revision 1.53
diff -r1.53 doc.l
53a54,55
> 
> /// a flag that tells parseDoc() if a @param command was encountered.
54a57,60
> 
> /// a flag that tells parseDoc() if a @return command was encountered.
> static bool                 hasReturnCommand; 
> 
1664a1671
>                                           hasReturnCommand = TRUE;
2789,2790c2796,2802
< void parseDoc(OutputDocInterface &od,const char *fileName,int startLine,
<               const char *clName,MemberDef *md,const QCString &docString)
---
> void parseDoc(OutputDocInterface &od,
>               const char *fileName,
> 	      int startLine,
>               const char *clName,
> 	      MemberDef *md,
> 	      const QCString &docString,
> 	      bool detailedDescription)
2798c2810,2811
<   hasParamCommand = FALSE;
---
>   hasParamCommand = FALSE;  // global variable, checked after parsing
>   hasReturnCommand = FALSE; // global variable, checked after parsing
2803,2804c2816,2821
<   parseDocument(od,docString);
< 
---
>   parseDocument(od,docString); // runs the lex parser on the documentation block.
>   
>   /* if a param command exists make sure the documentation matches the
>    * argument list.
>    * if it doesn't issue a warning.
>    */
2823c2840
<       }
---
>       }//for
2840,2842c2857,2868
< 	}
<       }
<     }
---
> 	}//for argument list iterator
>       }//if found
>     }//if argument list
>   }//if hasParamCommand
> 
>   /* now that we know if the documentation contains param and return commands
>      check again the warnings.
>    */  
>   
>   if (detailedDescription && memberDef && Config_getBool("WARN_IF_UNDOCUMENTED"))
>   {
>     memberDef->warnIfUndocumented(hasParamCommand,hasReturnCommand);

*****CVS exited normally with code 1*****

===================================================================
RCS file: /u/kp3softd/cvsroot/src/memberdef.h,v
retrieving revision 1.54
diff -r1.54 memberdef.h
125c125,126
< 
---
>     bool hasReturnValue() const;
>     bool hasArguments() const; 
162c163,165
<     void warnIfUndocumented();
---
> 
>     void warnIfUndocumented(bool AssumeParamCommandDocumented  = true,
>                             bool AssumeReturnCommandDocumented = true);

*****CVS exited normally with code 1*****

cvs diff memberdef.cpp (in directory C:\cvs\src)
Index: memberdef.cpp
===================================================================
RCS file: /u/kp3softd/cvsroot/src/memberdef.cpp,v
retrieving revision 1.80
diff -r1.80 memberdef.cpp
1208c1208,1213
<       parseDoc(ol,m_defFileName,m_defLine,scopeName,this,detailed+"\n");
---
>       parseDoc(ol,
>                m_defFileName,
>                m_defLine,scopeName,
>                this,
>                detailed+"\n",
>                true); // detailed description
1479c1484,1493
< void MemberDef::warnIfUndocumented()
---
>  /**
>     Creates a warning if not documented.
>     This includes the case where a function has no detailed description
>     but contains parammeters or a return value.
> 
>     \param AssumeParamCommandDocumented  - set to false if you are sure there is no param command in the detailed documentation
>     \param AssumeReturnCommandDocumented - set to false if you are sure there is no return commnad in the detailed documentation
>    */
> void MemberDef::warnIfUndocumented(bool AssumeParamCommandDocumented,
>                                    bool AssumeReturnCommandDocumented)
1495c1509,1543
<     t="file", d=fd;
---
>     t="file", d=fd;  
>   
>   if (d && d->isLinkable() && !isDocumentedFriendClass())
>   { 
>     
>   
> 
>     bool completlyUndocumented =  !isLinkable() && (name().find('@')==-1);
>     
>     bool ParamsUndocumented = hasArguments() &&
>                               (!AssumeParamCommandDocumented ||
>                                !isDetailedSectionLinkable());
>   
>     bool ReturnUndocumented = hasReturnValue() &&
>                               (!AssumeReturnCommandDocumented ||
>                                !isDetailedSectionLinkable());
> 
>     char* warning = NULL; // default is no warning
>     
>     if (completlyUndocumented) 
>     {
>       warning = "is not documented";
>     }
>     else if (ParamsUndocumented && ReturnUndocumented)
>     {
>       warning = "has undocumented parameters and an undocumented return value";
>     }
>     else if (ParamsUndocumented && !ReturnUndocumented)
>     {
>       warning = "has undocumented parameters";
>     }
>     else if (!ParamsUndocumented && ReturnUndocumented)
>     {
>       warning = "has an undocumented return value";
>     }//if
1497,1500c1545,1555
<   if (d && d->isLinkable() && !isLinkable() && !isDocumentedFriendClass()
<       && name().find('@')==-1)
<    warn_undoc(m_defFileName,m_defLine,"Warning: Member %s of %s %s is not documented.",
<         name().data(),t,d->name().data());
---
>     if (warning != NULL) 
>     {
>       warn_undoc(m_defFileName,
>                  m_defLine,
>                  "Warning: Member %s of %s %s %s.",
>                  name().data(),
>                  t,
>                  d->name().data(),
>                  warning);
>     }//if
>   }//if
1733a1789,1812
> 
> /**
>   Checks if this is a function with arguments (parameters).
>   @return true - has arguments  , false - no arguments.
>  */
> bool MemberDef::hasArguments() const
> {
>    if (!isFunction()) return false;
>    ArgumentList *tempArgList=isDocsForDefinition() ? 
>                                argumentList() : declArgumentList();
>            
>    return ((tempArgList!=NULL) && !tempArgList->isEmpty());
> }
> 
> /**
>   Checks if this is a function with a return value.
>   @return true - has a (non void) return value, false - otherwise.
>   @todo make sure that all supported computer languages use the "void" type.
>  */
> bool MemberDef::hasReturnValue() const
> {
>     if (!isFunction()) return false;
>     return !(type.contains("void"));      
> }
\ No newline at end of file

*****CVS exited normally with code 1*****

[Doxygen-develop] Patch: Undoumented Compound Warning

[Itai F. <ita...@ya...>]

Hi,

Doxygen does not report undocumented compounds (even when doxyfile is set appropriatly).

The attached patch fixes that.

Itai

cvs diff doxygen.cpp (in directory C:\cvs\src)
Index: doxygen.cpp
===================================================================
RCS file: /u/kp3softd/cvsroot/src/doxygen.cpp,v
retrieving revision 1.99
diff -r1.99 doxygen.cpp
3067c3067,3068
<     else if (bName.right(2)!="::")
---
>     if ((!cd || !cd->hasDocumentation()) && 
>         bName.right(2)!="::")

*****CVS exited normally with code 1*****




---------------------------------
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage

[Doxygen-develop] Xml & Page & Link

[<ca...@Cr...>]

    Hi.
    There are some question on xml output.=20
Most of all links (ref) use syntax <ref refid=3DID>, why link to the =
subsection use another syntax <link linkend=3DSOME>? And why SOME is not =
is a ID of the section.
=20
    For example (some part of example\page.cfg), lets there is a page :
      <compounddef id=3D"page1" kind=3D"page">
...
        <sect2 id=3D"subsection1"></sect2>
...
    </compounddef>
=20
  At doxygen output a reference to the section looks like <link =
linkend=3D"page1_subsection1">Link</link>
-------------------------------------------------
    Why it is not used syntax:
      <compounddef id=3D"page1" kind=3D"page">
...
        <sect2 id=3D"page1_subsection1"></sect2>
                        ~~~~~~~~~~~~~~
...
    </compounddef>
=20
<ref refid=3D"page1_subsection1" kindref=3D"page">Link</ref>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--------------------------------------------------
    Ore syntax
      <compounddef id=3D"page1" kind=3D"page">
...
        <sect2 id=3D"page1_subsection1"></sect2>
                        ~~~~~~~~~~~~~~
...
    </compounddef>
=20
<link linkend=3D"page1_subsection1">Link</link>
--------------------------------------------------
=20
- Alexandr Chelpanov -

[Doxygen-develop] xml

[<ca...@Cr...>]

    There are some compilation problems on Microsoft VC in xml files:
=20
1. addon\doxmlparser\src\basehandler.h:
    template<class T> class ElementMapper {
    ...
    typedef StartElementHandler<T> StartElementHandlerT;
                                            ~~~
    typedef EndElementHandler<T> EndElementHandlerT;
                                            ~~~
}
=20
simplified removing <T> will remove errors:
    template<class T> class ElementMapper {
    ...
    typedef StartElementHandler StartElementHandlerT;
    typedef EndElementHandler EndElementHandlerT;
}
=20
gcc compilate both codes.
=20
2. addon\doxmlparser\test\main.cpp & =
addon\doxmlparser\examples\metrics\main.cpp
    definition of exit() not found -- #include <stdio.h> remove error
=20
3. addon\doxmlparser\test\main.cpp:
...
        IDocSimpleSect *ss =3D dynamic_cast<IDocSimpleSect*>(ss);
...
        IDocRef *ref =3D dynamic_cast<IDocRef*>(ref);
...=20
    etc.

    Please change to
...
        IDocSimpleSect *ss =3D dynamic_cast<IDocSimpleSect*>(doc);
...
        IDocRef *ref =3D dynamic_cast<IDocRef*>(doc);
...=20
  etc
=20
------------------------
Errors at doxygen XML outputs, when generating reference to a group=20
=20
    Small sample:
/** @defgroup group1 group */
=20
/** @ingroup group1=20
 *  @see group1
 */
class C1 {};

    Another sample examples\group.cfg
=20
-----------------------
    Thanks when remove. - Alexandr Chelpanov -

[Doxygen-develop] Patch: A group that has more than one parent groups.

[Itai F. <ita...@ya...>]

Hi all,

I've noticed that in the modules tree generated by doxygen, each module appears only once. Nevertheless, some modules might have more than one parent groups.

The reason is that each node in the tree is marked as visited, and then skipped. I suggest to remove this check. Will this patch have implications on other trees that doxygen makes ?

This is my first patch submission, so I hope I did it right. Dimitry, I'm sorry for emailing you directly , it took me time to find this group's email, and "discover" WinCVS.

thnx,

Itai Frenkel

 

cvs diff index.cpp (in directory C:\cvs\src)
Index: index.cpp
===================================================================
RCS file: /u/kp3softd/cvsroot/src/index.cpp,v
retrieving revision 1.71
diff -r1.71 index.cpp
2231c2231,2233
<   if (!gd->visited && (!gd->isASubGroup() || level>0))
---
>   /* Some groups should appear twice under different parent-groups.
>      That is why we should not check if it was visited */    
>   if (/*!gd->visited && */(!gd->isASubGroup() || level>0))
2506c2508
<     gd->visited=TRUE;
---
>     /*gd->visited=TRUE;*/

*****CVS exited normally with code 1*****

 



---------------------------------
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!

Re: [Doxygen-develop] Dot doxfont missing

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

On Thu, Mar 07, 2002 at 01:35:58PM -0600, Scot Wilcoxon wrote:
> I tried to produce Doxygen graphics in a configuration where "dot" was not on 
> the development machine, so the "dot" command redirected the request and files 
> to the machine with "dot" installed.
> 
> The resulting chart had no labels, because the Doxygen font was not present.
> 
> A configuration option to not use doxfont would be nice.  Default fonts are 
> better than no labels.  Or allow configuration of the font name.

In the latest versions, doxygen does not use/produce doxfont anymore. It uses
Helvetica (translated to Arial on Windows), which should be available 
(doxygen will still produce a file Helvetica.ttf just in case). 

Regards,
  Dimitri

[Doxygen-develop] Dot doxfont missing

[Scot W. <sc...@wi...>]

I tried to produce Doxygen graphics in a configuration where "dot" was not on 
the development machine, so the "dot" command redirected the request and files 
to the machine with "dot" installed.

The resulting chart had no labels, because the Doxygen font was not present.

A configuration option to not use doxfont would be nice.  Default fonts are 
better than no labels.  Or allow configuration of the font name.

[Doxygen-develop] Updated Czech translation

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

Hi, 

The only difference is that the TranslatorAdapter...13 was replaced 
by the Translator as the base class.

See you,
  Petr

 <<translator_cz.zip>> 

-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)

[Doxygen-develop] Updated Portuguese translation

[Rui L. <rui...@ya...>]

Hi all!

Here is the updated Portuguese translation.


Byes,
----
Rui Lopes
www.ruilopes.com

[Doxygen-develop] [patch] 1.2.14 Segfault

[Aric C. <ac...@al...>]

Found a nasty little segfault (v1.2.14) , that was hitting me when I
wanted to generate a LaTeX template from a Doxyfile config file.  When
I used something like:

doxygen -w latex header.tex doxygen.sty Doxyfile

It would segfault right away.  It turned out that a translator wasn't
instantiated but LatexGenerator depends on it.  I have included the
patch below.  I have tested the LaTeX part myself, but not the HTML
part.  Since the code is identical, I assume it would work as well.
It is fairly small so it should be easy to verify its correctness.
Note that I removed the explicit check if outputLanguage is empty.
This does not seem to be needed since setTranslator() would then
(correctly) pick "english" as the default.  With that isEmpty() check
we could end up with an uninstantiated Translator again, since if the
string was empty setTranslator() wouldn't get called.

Anyways I hope this is useful to other people.

-- 
Aric Cyr <acyr at alumni dot uwaterloo dot ca>

[Doxygen-develop] Re: Compiling Doxygen with GCC under Windows?

[Ryunosuke S. <ryu...@ca...>]

Hi,

> Has anybody successfully compiled Doxygen with GCC under Windows?

I can't too. I find that some settings of Makefile changed.
I'm trying to correct.Please just a moment.

Regards,
Ryunosuke Sato

AW: [Doxygen-develop] Compiling Doxygen with GCC under Windows?

[Brandt, O. / E. - B. <Oli...@Le...>]

Maybe I didn't get you right: Are you talking about CYGWIN-gcc or about
MINGW-gcc?
If it's CYGWIN you have to add the following lines in "qglobal.h":

#elif defined(__CYGWIN32__)
#define _OS_WIN32_

Cheers,
Oliver

> -----Urspr=FCngliche Nachricht-----
> Von: Brandt, Oliver / ELE - BS [mailto:Oli...@Le...]
> Gesendet am: Donnerstag, 21. Februar 2002 19:29
> An: 'dox...@li...'
> Betreff: AW: [Doxygen-develop] Compiling Doxygen with GCC=20
> under Windows?
>=20
> You have to run "make.bat mingw". That should be all.
> =20
> Regards,
> Oliver
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: Roy Leonard [mailto:Roy...@wd...]
> Gesendet am: Donnerstag, 21. Februar 2002 19:22
> An: 'dox...@li...'
> Betreff: [Doxygen-develop] Compiling Doxygen with GCC under Windows?
>=20
>=20
>=20
>=20
> Hi,=20
>=20
> Has anybody successfully compiled Doxygen with GCC under Windows?=20
>=20
> My first trivial attempt generates the following error:=20
>=20
> g++ -c -O -I../qtools -o ../objects/config.o config.cpp=20
> In file included from ../qtools/qiodevice.h:42,=20
>                  from ../qtools/qfile.h:42,=20
>                  from ../qtools/qfileinfo.h:42,=20
>                  from config.l:27:=20
> ../qtools/qglobal.h:132: #error "Qt has not been ported to=20
> this OS - talk to
> qt-=20
> bu...@tr..."=20
>=20
> Anybody got any suggestions?  Or should I just go out and get MSVC?=20
>=20
> Cheers,=20
>=20
> Roy=20
>=20
>=20
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>=20

AW: [Doxygen-develop] Compiling Doxygen with GCC under Windows?

[Brandt, O. / E. - B. <Oli...@Le...>]

You have to run "make.bat mingw". That should be all.
=20
Regards,
Oliver

-----Urspr=FCngliche Nachricht-----
Von: Roy Leonard [mailto:Roy...@wd...]
Gesendet am: Donnerstag, 21. Februar 2002 19:22
An: 'dox...@li...'
Betreff: [Doxygen-develop] Compiling Doxygen with GCC under Windows?




Hi,=20

Has anybody successfully compiled Doxygen with GCC under Windows?=20

My first trivial attempt generates the following error:=20

g++ -c -O -I../qtools -o ../objects/config.o config.cpp=20
In file included from ../qtools/qiodevice.h:42,=20
                 from ../qtools/qfile.h:42,=20
                 from ../qtools/qfileinfo.h:42,=20
                 from config.l:27:=20
../qtools/qglobal.h:132: #error "Qt has not been ported to this OS - =
talk to
qt-=20
bu...@tr..."=20

Anybody got any suggestions?  Or should I just go out and get MSVC?=20

Cheers,=20

Roy=20