doxygen-users — List for users of doxygen

[Doxygen-users] Is there a Doxygen plug-in for Eclipse Luna ?

[Carl S. <ce....@ya...>]

Greetings

      Subject line pretty much explains it. When I am in QtCreator the plugin is nice, so I am looking for something equivalent for Luna...  maybe one that actually understand FORTRAN too.... well a guy can dream.

Regards
Carl

[Doxygen-users] Doc for C# enum is not extracted (despite public and \file).

[tobias <ts...@ex...>]

Hey,I tried to find a solution for my problem but failed. This is the
situation:One of my C# sources has multiple enums. The file gets parsed and
I added a \file comment for doxygen. However, even though the enums are
public, they won't show up in the generated html doc.I updated to the latest
Doxygen (installer) v1.8.7 and have no idea if my config is bad or if
something else is.Source now looks like
this:http://hastebin.com/udubamobis.csDoxgen
Config:http://hastebin.com/ubusulocev.txtThanks in advance for any help
provided.Tobias



--
View this message in context: http://doxygen.10944.n7.nabble.com/Doc-for-C-enum-is-not-extracted-despite-public-and-file-tp6741.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] Rejects C++ overloaded methods w/ default parameters

[Dimitri v. H. <do...@gm...>]

On 21 Jul 2014, at 19:14 , MK <mk...@co...> wrote:

> On Mon, 21 Jul 2014 14:46:06 +0000
> "Ferro, Alasdair" <Ala...@me...> wrote:
> 
>> Make sure your "std::" prefixes match - Doxygen is far less forgiving
>> that the C++ compiler on this!
> 
> If that's the issue, it's not a matter of "being less forgiving",
> it's a matter of being wrong, I think, since the .cpp files use
> namespace std whereas the .hpp ones don't.   All of the other methods
> are the same in this regard and they come out okay.

No, it is a matter of giving doxygen incomplete input. Unlike the
compiler which reads the <vector> include file and stops with an error if
it cannot find it, doxygen doesn't parse this file (unless you make it part 
of the INPUT) and as a result it doesn't know about the existence of a
namespace 'std' with a class 'vector' in it. So it cannot assume the
arguments match if there are multiple candidate definitions to choose from.

Since std::vector is such a common use-case, I've added the option
BUILTIN_STL_SUPPORT, which you can enable to make the most common STL
classes known to doxygen.

> 
> BUT: Adding the full namespace to the params in the .cpp works to get
> the documentation out.    I'm okay with that, even if it does look a
> little inconsistent.   Life is not perfect ;)

I hope it is a little more perfect with the info above ;-)

Regards,
  Dimitri

Re: [Doxygen-users] Rejects C++ overloaded methods w/ default parameters

[MK <mk...@co...>]

On Mon, 21 Jul 2014 14:46:06 +0000
"Ferro, Alasdair" <Ala...@me...> wrote:

> Make sure your "std::" prefixes match - Doxygen is far less forgiving
> that the C++ compiler on this!

If that's the issue, it's not a matter of "being less forgiving",
it's a matter of being wrong, I think, since the .cpp files use
namespace std whereas the .hpp ones don't.   All of the other methods
are the same in this regard and they come out okay.

BUT: Adding the full namespace to the params in the .cpp works to get
the documentation out.    I'm okay with that, even if it does look a
little inconsistent.   Life is not perfect ;)

Thanks!
MK

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)

Re: [Doxygen-users] Rejects C++ overloaded methods w/ default parameters

[Ferro, A. <Ala...@me...>]

MK,

Make sure your "std::" prefixes match - Doxygen is far less forgiving that the C++ compiler on this!

Alasdair

-----Original Message-----
From: MK [mailto:mk...@co...] 
Sent: 21 July 2014 14:37
To: dox...@li...
Subject: [Doxygen-users] Rejects C++ overloaded methods w/ default parameters

I'm not sure why this doesn't work; I have overloaded constructors with
default values that came out fine, overloaded methods, and methods w/
default params, but this is the only overloaded method with default
parameters.  It gets left out of the documentation and an error is
reported (I've added indentation to make this more readable):

Searching for member function documentation...
led8x8.cpp:203: warning: no matching class member found for 
void led8x8::scroll (
         const vector< led8x8Image * > &images,
         ledDirection_t direction, 
         int delay
) 
Possible candidates:
void led8x8::scroll (
         const std::vector< led8x8Image * > &,
         ledDirection_t, 
         int=5
) 
void led8x8::scroll (
         std::string,
         ledDirection_t, 
         int=5
)

led8x8.cpp:224: warning: no matching class member found for 
void led8x8::scroll (
         string msg, 
         ledDirection_t direction,
         int delay
)
Possible candidates:
void led8x8::scroll (
          const std::vector< led8x8Image * > &,
          ledDirection_t, 
          int=5
)
void led8x8::scroll(
          std::string,
          ledDirection_t, 
          int=5
)      

As you can see, these *do* match up; this code compiles flawlessly.

Is there anyway around this or do I have to edit these into the html
file manually? 

MK

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Doxygen-users mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] Rejects C++ overloaded methods w/ default parameters

[MK <mk...@co...>]

I'm not sure why this doesn't work; I have overloaded constructors with
default values that came out fine, overloaded methods, and methods w/
default params, but this is the only overloaded method with default
parameters.  It gets left out of the documentation and an error is
reported (I've added indentation to make this more readable):

Searching for member function documentation...
led8x8.cpp:203: warning: no matching class member found for 
void led8x8::scroll (
         const vector< led8x8Image * > &images,
         ledDirection_t direction, 
         int delay
) 
Possible candidates:
void led8x8::scroll (
         const std::vector< led8x8Image * > &,
         ledDirection_t, 
         int=5
) 
void led8x8::scroll (
         std::string,
         ledDirection_t, 
         int=5
)

led8x8.cpp:224: warning: no matching class member found for 
void led8x8::scroll (
         string msg, 
         ledDirection_t direction,
         int delay
)
Possible candidates:
void led8x8::scroll (
          const std::vector< led8x8Image * > &,
          ledDirection_t, 
          int=5
)
void led8x8::scroll(
          std::string,
          ledDirection_t, 
          int=5
)      

As you can see, these *do* match up; this code compiles flawlessly.

Is there anyway around this or do I have to edit these into the html
file manually? 

MK

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)

[Doxygen-users] Function pointer weird behaviour

[Jorge L. Z. M. <jor...@gm...>]

Hi all,

When generating XML based documentation for a function pointer typedef I
get the XML output without the <param> tags and thus I can not get the
types of the parameters.

For example:

/**
 * A function pointer
 * @param a The first param
 * @param b The second param
 */
typedef void (*function_ptr)(int a, int b);

I only get on the generated output:
<memberdef kind="typedef" id="main_8c_1aeb1ee3af864aafa7e11ce9d0854ddc29"
prot="public" static="no">
  <type>void(*</type>
  <definition>function_ptr</definition>
  <argsstring>)(int a, int b)</argsstring>
  <name>function_ptr</name>
  <briefdescription>
    </briefdescription>
  <detaileddescription>
    <para>A function pointer</para>
    <para>
      <parameterlist kind="param">
        <parameteritem>
          <parameternamelist>
            <parametername>a</parametername>
          </parameternamelist>
          <parameterdescription>
            <para>The first param </para>
          </parameterdescription>
        </parameteritem>
        <parameteritem>
          <parameternamelist>
            <parametername>b</parametername>
          </parameternamelist>
          <parameterdescription>
            <para>The second param </para>
          </parameterdescription>
        </parameteritem>
      </parameterlist>
    </para>
  </detaileddescription>
  <inbodydescription>
        </inbodydescription>
</memberdef>

But no <param> tag like any other function.
Is this intentional? Is it a bug?

Best Regards

Re: [Doxygen-users] TAGFILES not working consistently in 1.8.7 (RHEL6)

[Keith R. <Kei...@ne...>]

To be honest, the warning may be nothing to do with it, but I have no idea. We have gone back to 1.8.6 as we need the tag file functionality to work.

> -----Original Message-----
> From: didje [mailto:dia...@pd...]
> Sent: 15 July 2014 12:51
> To: dox...@li...
> Subject: Re: [Doxygen-users] TAGFILES not working consistently in 1.8.7
> (RHEL6)
> 
> Sorry, my mistake.
> I see the problem with Red Hat 6 generated documentation too.
> However, I don't see what the practical effect of it is. All my references
> appear to be functioning nonetheless.
> 
> 
> 

[Doxygen-users] Errors when use Doxygen in Linux

[Zhang, C. <cz...@ma...>]

Hi,  all,


I meet a problem when I use Doxygen in Linux. The following is the information:



(doxywizard:8896): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed


I don't know what happened, and I get nothing after running the configuration.



Best,
Chao

[Doxygen-users] VHDL automatic links

[<Gui...@in...>]

Hi,
I have been trying without success to generate automatic links for VHDL signals and processes. The documentation is clear about automatic link generation for classes, but I have not managed to do it in VHDL.
Many thanks.

[Doxygen-users] Create links to subdirs

[Florian L. <mai...@xg...>]

Hello,

I'm taking over a project that used doxys (based on doxygen) for 
documentation and will be converting it back to pure doxygen.

In each directory D we have a file D.dox with a @dir D tag.

Is there a way I can link to these directory homepages from the @mainpage?

We had something like $D$ but this is not working anymore.

Thanks!

Florian

[Doxygen-users] Doxygen-Sphinx-breathe integration for multiple directories

[BinduSRao <bin...@gm...>]

Hi,

I am new to usage of Doxygen, Sphinx and Breathe.
My requirement is to generate a html file per directory, which contains
source files written in C language.

To illustrate:
dir1
  - file1.h
  - file1.c

dir2
  - file2.h
  - file2.c
...

I used Doxygen to generate xml files, which looks ok.(file1_h.xml,
file1_c.xml, file2_h.xml and file2_c.xml)
When I try to generate html files using Sphinx-Breathe for dir1 and dir2, I
observe that though 2 files are generated,
both the files contain dir1 and dir2 contents.

ie. dir1.html/dir2.html -> file1_h.xml, file1_c.xml, file2_h.xml and
file2_c.xml

However, I would like to generate as follows:
dir1.html -> file1_h.xml, file1_c.xml,
dir2.html -> file2_h.xml and file2_c.xml

How can I achieve this? 
Could anyone help me with this please?

   




--
View this message in context: http://doxygen.10944.n7.nabble.com/Doxygen-Sphinx-breathe-integration-for-multiple-directories-tp6731.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] TAGFILES not working consistently in 1.8.7 (RHEL6)

[didje <dia...@pd...>]

Sorry, my mistake.
I see the problem with Red Hat 6 generated documentation too.
However, I don't see what the practical effect of it is. All my references
appear to be functioning nonetheless.



--
View this message in context: http://doxygen.10944.n7.nabble.com/TAGFILES-not-working-consistently-in-1-8-7-RHEL6-tp6688p6730.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] TAGFILES not working consistently in 1.8.7 (RHEL6)

[didje <dia...@pd...>]

I notice the same warning message, but in slightly different circumstances.
Basically, it occurs when library A includes a tag file to library B where
both libraries have been generated using 1.8.7 on Red Hat 5.
Where both libraries are generated using Red Hat 6 (1.8.7), I do not see
this warning message.
However, though I see the warning message for the Red Hat 5 version, the
resulting documentation appears to be the same as for the Red Hat 6 version,
so I don't know what ill-effect it is having.




--
View this message in context: http://doxygen.10944.n7.nabble.com/TAGFILES-not-working-consistently-in-1-8-7-RHEL6-tp6688p6728.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] Briefer comments

[Clemens F. <c....@os...>]

> From: Florian Lindner
> Date: 15.07.2014 10:56
>
> Hello,
>
> I have a lot of comments like that:
>
>    /**
>     * @brief Limit of iterations during one timestep.
>     */
>    int _maxIterations;
>
> which makes it three lines of code for one line of comment. What is the best
> way to achieve the same commentary with one line of code?
>
> At http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html all comments
> are multi-line.
>
> Thanks,
> Florian
>

Hi Florian.

It is too easy to write one-liners:

/** Limit of iterations during one timestep. */
int _maxIterations;

//! Limit of iterations during one timestep.
int _maxIterations;

/// Limit of iterations during one timestep.
int _maxIterations;

int _maxIterations; ///< Limit of iterations during one timestep.


If you have  JAVADOC_AUTOBRIEF=YES then you can omitt the @brief:

JAVADOC_AUTOBRIEF=NO:

/** @brief Limit of iterations during one timestep. More than one 
sentence ... */
int _maxIterations;

JAVADOC_AUTOBRIEF=YES:

/// Limit of iterations during one timestep. More than one sentence ...
int _maxIterations;

Clemens

Re: [Doxygen-users] Briefer comments

[Stefan L. <kai...@ex...>]

Hi Florian.

>From your link I can tell that for example
int _maxIterations; ///< Limit of iterations during one timestep.
Should work.

Just scroll a bit down for a lot of alternatives regarding 2 liners and 1
liners and choose the one that you like most.

Kind regards,
Stefan.
-----Original Message-----
From: Florian Lindner [mailto:mai...@xg...]
Sent: Tuesday, July 15, 2014 10:56 AM
To: dox...@li...
Subject: [Doxygen-users] Briefer comments

Hello,

I have a lot of comments like that:

  /**
   * @brief Limit of iterations during one timestep.
   */
  int _maxIterations;

which makes it three lines of code for one line of comment. What is the
best way to achieve the same commentary with one line of code?

At http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html all comments
are multi-line.

Thanks,
Florian


--------------------------------------------------------------------------
----
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck Code
Sight - the same software that powers the world's largest code search on
Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Doxygen-users mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-users

-- 
--
Exit Games | www.exitgames.com | @exitgames | +49 40 413 596 0

Executives Christof Wegmann CTO, Wim de Smet CFO
Trade Registry / Amtsgericht Hamburg, Germany HRB 85991

++ Add Chat: http://j.mp/PhotonChat
++ Start Turnbased: http://j.mp/PhotonTurnbased
++ Unity Networking that just works: http://j.mp/PhotonUnity
++ Follow http://twitter.com/exitgames for Photon announcements

Re: [Doxygen-users] Segfault when using tag files from documentation that has been compiled using tag files

[Torsten M. <t0...@gm...>]

Hello Dimitri,

Thanks for your quick reply.

On 14.07.2014, at 20:29, Dimitri van Heesch <do...@gm...> wrote:

> Hi Torsten,
> 
> Seems like a symbol definition has itself as container, which is not good (and not possible normally).
> Can you enable the commented out code in Definition::qualifiedName()?
> That will print the name of the symbol. Would be good to know if that symbol name came from the tag file.

I followed your advise. Indeed the recursion happens on a symbol coming from the tag file of library A, which was used already referenced by the Doxyfile of library B and used again by the Doxyfile of library C.

------------------------------------------------------------------------
$ doxygen Doxyfile
[...]
start sc_core::qualifiedName() localName=sc_core
end sc_core::qualifiedName()=sc_core
start sc_core::sc_in< sc_dt::sc_logic >::qualifiedName() localName=sc_in< sc_dt::sc_logic >
start sc_core::sc_in< sc_dt::sc_logic >::qualifiedName() localName=sc_in< sc_dt::sc_logic >
start sc_core::sc_in< sc_dt::sc_logic >::qualifiedName() localName=sc_in< sc_dt::sc_logic >
[... forever until segfault]
------------------------------------------------------------------------

In the tag file of library A, I find this symbol registered as:

  <class kind="class">sc_core::sc_in&lt; sc_dt::sc_logic &gt;</class>

In the tag file of library B, I find this symbol again registered as:

  <compound kind="namespace">
    <name>sc_core::sc_in&lt; sc_dt::sc_logic &gt;</name>
    <filename>a00563.html</filename>
  </compound>

This seems wrong to me and could explain, why the definition has itself as container.

> A workaround you could try is to guard the "else" against simple self recursion, i.e. replace
> 
>  if (m_impl->outerScope->name()=="<globalScope>")
>  {
>    m_impl->qualifiedName = m_impl->localName;
>  }
>  else
>  {
> 
> with
> 
>  if (m_impl->outerScope->name()=="<globalScope>")
>  {
>    m_impl->qualifiedName = m_impl->localName;
>  }
>  else if (m_impl->outputScope!=this)
>  {
> 
> no guarantee that it will not end up in a recursive loop elsewhere though.

I tried this and now indeed doxygen passes the "Adding xrefitems..." phase to get stuck in the "Generating namespace index..." phase, which seems to be coherent with the above observation of the tag file content.

GDB backtrace gives:

------------------------------------------------------------------------
(gdb) bt
#0  0x0000003275079367 in _int_malloc () from /lib64/libc.so.6
#1  0x000000327507a991 in malloc () from /lib64/libc.so.6
#2  0x000000000078e136 in QCString::QCString (this=0x7fffff3ff0c0, size=21)
    at scstring.cpp:41
#3  0x000000000078f018 in QCString::mid (this=0x15be6b0, index=23, len=20)
    at scstring.cpp:393
#4  0x000000000057bc34 in NamespaceDef::isLinkableInProject (this=0x15be6a0)
    at namespacedef.cpp:1049
#5  0x00000000005c9a43 in namespaceHasVisibleChild (nd=0x15be6a0,
    includeClasses=false) at util.cpp:7978
#6  0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
    includeClasses=false) at util.cpp:7982
#7  0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
    includeClasses=false) at util.cpp:7982
#8  0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
    includeClasses=false) at util.cpp:7982
#9  0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
    includeClasses=false) at util.cpp:7982
#10 0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
    includeClasses=false) at util.cpp:7982
------------------------------------------------------------------------

Looking at the local variables:

------------------------------------------------------------------------
(gdb) up
#1  0x000000327507a991 in malloc () from /lib64/libc.so.6
(gdb) up
#2  0x000000000078e136 in QCString::QCString (this=0x7fffff3ff0c0, size=21)
    at scstring.cpp:41
41	    m_data = (char *)malloc(size);
(gdb) up
#3  0x000000000078f018 in QCString::mid (this=0x15be6b0, index=23, len=20)
    at scstring.cpp:393
393	    SCString s( len+1 );
(gdb) up
#4  0x000000000057bc34 in NamespaceDef::isLinkableInProject (this=0x15be6a0)
    at namespacedef.cpp:1049
1049	  if (extractAnonNs &&                             // extract anonymous ns
(gdb) up
#5  0x00000000005c9a43 in namespaceHasVisibleChild (nd=0x15be6a0,
    includeClasses=false) at util.cpp:7978
7978	      if (cnd->isLinkableInProject() && cnd->localName().find('@')==-1)
(gdb) print cnd
$1 = (NamespaceDef *) 0x15be6a0
(gdb) print nd
$4 = (NamespaceDef *) 0x15be6a0
(gdb) print includeClasses
$5 = false
(gdb) up
#6  0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
    includeClasses=false) at util.cpp:7982
7982	      else if (namespaceHasVisibleChild(cnd,includeClasses))
(gdb) print nd
$6 = (NamespaceDef *) 0x15be6a0
(gdb) print includeClasses
$7 = false
(gdb) print cnd
$8 = (NamespaceDef *) 0x15be6a0
------------------------------------------------------------------------

… this seems to indicate that doxygen is again recursing on a node linked to itself.

Do you have any more suggestions how to localize the root of the problem?

> Regards,
>  Dimitri

Regards,

Torsten

> 
> On 14 Jul 2014, at 15:48 , Torsten Mähne <t0...@gm...> wrote:
> 
>> Hello,
>> 
>> I think that I've run into the same segfault that has been reported on 20 Dec 2013 by JohnOldman <http://doxygen.10944.n7.nabble.com/Segfault-when-using-tag-files-from-documentation-that-has-been-compiled-using-tag-files-td6414.html#a6420>.
>> 
>> On 22 Dec 2013, 12:11:47, Dimitri van Heesch <doxygen@gm…> wrote:
>>> On 22 Dec 2013, at 12:31, JohnOldman <j.r.greis@...> wrote:
>>> 
>>>> UPDATE:
>>>> I've tried now with a whole bunch of different versions and it seems like
>>>> the problem first arises as of 1.6.2:
>>>> 1.6.1 and 1.6.0 work, 1.6.2 and about half a dozen other newer versions I've
>>>> tried give me the same segfault. Could this be an incompatibility with my
>>>> distribution? I'm using Scientific Linux 6.
>> 
>> I also observed the segfault on Scientific Linux 6 (RHEL 6 clone) on both, i686 and x86_64 platforms. I also have a situation, where I generate source code documentation for a library C, which depends in a chain on two other libraries B and A: C->B->A. I added the tag files generated by Doxygen for libraries B and A to the Doxyfile of library C.
>> 
>> When running doxygen on the Doxyfile of library C, the segfault happens always in the phase Adding xrefitems…
>> 
>> On my side, I don't observe the problem on doxygen 1.5.7.1 (Scientific Linux 5 i686).
>> 
>>> It is more likely a bug in doxygen introduced in 1.6.2 and triggered by your specific example.
>>> Can you grab the latest doxygen source from GitHub and compile it using ./configure --debug and then run it from a debugger and/or from valgrind. 
>>> That might give an indication where the problem is located.
>> 
>> I did clone the doxygen repository from Github (commit g3a5e6ac), build Doxygen with debug symbols as suggested and executed doxygen on the problematic Doxyfile from within gdb:
>> 
>> ------------------------------------------------------------------------
>> 
>> $ gdb ~/bin/doxygen
>> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
>> Copyright (C) 2010 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from ~/bin/doxygen...done.
>> (gdb) run Doxyfile
>> Starting program: ~/bin/doxygen Doxyfile
>> [Thread debugging using libthread_db enabled]
>> …
>> Building group list...
>> Building directory list...
>> Building namespace list...
>> Building file list...
>> Building class list...
>> Associating documentation with classes...
>> Computing nesting relations for classes...
>> Building example list...
>> Searching for enumerations...
>> Searching for documented typedefs...
>> Searching for members imported via using declarations...
>> Searching for included using directives...
>> Searching for documented variables...
>> Building interface member list...
>> Building member list...
>> Searching for friends...
>> Searching for documented defines...
>> Computing class inheritance relations...
>> Computing class usage relations...
>> Flushing cached template relations that have become invalid...
>> Creating members for template instances...
>> Computing class relations...
>> Add enum values to enums...
>> Searching for member function documentation...
>> Building page list...
>> Search for main page...
>> Computing page relations...
>> Determining the scope of groups...
>> Sorting lists...
>> Freeing entry tree
>> Determining which enums are documented
>> Computing member relations...
>> Building full member lists recursively...
>> Adding members to member groups.
>> Computing member references...
>> Inheriting documentation...
>> Generating disk names...
>> Adding source references...
>> Adding xrefitems...
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000003275079367 in _int_malloc () from /lib64/libc.so.6
>> Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64 libgcc-4.4.6-4.el6.x86_64 libstdc++-4.4.6-4.el6.x86_64
>> (gdb) bt full
>> #0  0x0000003275079367 in _int_malloc () from /lib64/libc.so.6
>> No symbol table info available.
>> #1  0x000000327507a991 in malloc () from /lib64/libc.so.6
>> No symbol table info available.
>> #2  0x000000000043354f in QCString::duplicate (this=0x7fffff3ff130,
>>   str=0x8b84fc "::") at ../qtools/qcstring.h:304
>>       l = 2
>> #3  0x000000000078e0ff in QCString::QCString (this=0x7fffff3ff130,
>>   str=0x8b84fc "::") at scstring.cpp:61
>> No locals.
>> #4  0x00000000005c8f00 in getLanguageSpecificSeparator (lang=SrcLangExt_Unknown,
>>   classScope=false) at util.cpp:7746
>> No locals.
>> #5  0x00000000006da326 in Definition::qualifiedName (this=0x1bfe150)
>>   at definition.cpp:1358
>> No locals.
>> #6  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>>   at definition.cpp:1358
>> No locals.
>> #7  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>>   at definition.cpp:1358
>> No locals.
>> #8  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>>   at definition.cpp:1358
>> No locals.
>> #9  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>>   at definition.cpp:1358
>> No locals.
>> #10 0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>>   at definition.cpp:1358
>> No locals.
>> [...]
>> ------------------------------------------------------------------------
>> 
>> The backtrace continuous to mention Definition::qualifiedName thousands of times (I stopped after #10000).
>> 
>> ------------------------------------------------------------------------
>> (gdb) up
>> #1  0x000000327507a991 in malloc () from /lib64/libc.so.6
>> (gdb)
>> #2  0x000000000043354f in QCString::duplicate (this=0x7fffff3ff130,
>>   str=0x8b84fc "::") at ../qtools/qcstring.h:304
>> 304	    m_data = (char *)malloc(l+1);
>> (gdb)
>> #3  0x000000000078e0ff in QCString::QCString (this=0x7fffff3ff130,
>>   str=0x8b84fc "::") at scstring.cpp:61
>> 61	  duplicate(str);
>> (gdb)
>> #4  0x00000000005c8f00 in getLanguageSpecificSeparator (lang=SrcLangExt_Unknown,
>>   classScope=false) at util.cpp:7746
>> 7746	    return "::";
>> (gdb)
>> #5  0x00000000006da326 in Definition::qualifiedName (this=0x1bfe150)
>>   at definition.cpp:1358
>> 1358	           m_impl->localName;
>> (gdb) print m_impl
>> $1 = (DefinitionImpl *) 0x1bfe260
>> (gdb) print m_impl->localName
>> $2 = {m_data = 0x1c0eba0 "sc_in< sc_dt::sc_logic >"}
>> ------------------------------------------------------------------------
>> 
>> This localName is from library A and is actually defined in a namespace called sc_core.
>> 
>> Looking at the recursive implementation of Definition::qualifiedName() in the mentioned source file, it seems that the end recursion criteria is never fulfilled:
>> 
>> ------------------------------------------------------------------------
>> (gdb) l
>> 1353	  }
>> 1354	  else
>> 1355	  {
>> 1356	    m_impl->qualifiedName = m_impl->outerScope->qualifiedName()+
>> 1357	           getLanguageSpecificSeparator(getLanguage())+
>> 1358	           m_impl->localName;
>> 1359	  }
>> 1360	  //printf("end %s::qualifiedName()=%s\n",name().data(),m_impl->qualifiedName.data());
>> 1361	  //count--;
>> 1362	  return m_impl->qualifiedName;
>> (gdb) print m_impl->outerScope->m_impl->qualifiedName
>> $3 = {m_data = 0x0}
>> ------------------------------------------------------------------------
>> 
>> Maybe something goes wrong with the lookup through the tag files?
>> 
>> I hope you have some suggestion how to fix the problem. I can help with testing a potential fix.
>> 
>>> Regards,
>>> Dimitri
>> 
>> Best regards,
>> 
>> Torsten
>> 
>> 
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck&#174;
>> Code Sight&#153; - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Doxygen-users mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 

[Doxygen-users] Briefer comments

[Florian L. <mai...@xg...>]

Hello,

I have a lot of comments like that:

  /**
   * @brief Limit of iterations during one timestep.
   */
  int _maxIterations;

which makes it three lines of code for one line of comment. What is the best 
way to achieve the same commentary with one line of code?

At http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html all comments 
are multi-line.

Thanks,
Florian

[Doxygen-users] JavaScript Support

[Stephen R. <sru...@iq...>]

I am currently trying to get Doxygen to work with some JavaScript files I
have written.  I have viewed the "Extensions" page on the Doxygen site and
the links that are provided there for JavaScript are either no longer
available, or don't actually point to the extension being described.  Is
there another link I could use to get this Doxygen perl script extension
for JavaScript?

If not, how can I get Doxygen to work with JavaScript?

Thanks,

- Steve

-- 
Stephen T. Ruzzini
Co-Op, Software Development
IQ Inc.
Cell: (610) 804-2655

Re: [Doxygen-users] Segfault when using tag files from documentation that has been compiled using tag files

[Dimitri v. H. <do...@gm...>]

Hi Torsten,

Seems like a symbol definition has itself as container, which is not good (and not possible normally).
Can you enable the commented out code in Definition::qualifiedName()?
That will print the name of the symbol. Would be good to know if that symbol name came from the tag file.

A workaround you could try is to guard the "else" against simple self recursion, i.e. replace

  if (m_impl->outerScope->name()=="<globalScope>")
  {
    m_impl->qualifiedName = m_impl->localName;
  }
  else
  {

with

  if (m_impl->outerScope->name()=="<globalScope>")
  {
    m_impl->qualifiedName = m_impl->localName;
  }
  else if (m_impl->outputScope!=this)
  {

no guarantee that it will not end up in a recursive loop elsewhere though.

Regards,
  Dimitri


On 14 Jul 2014, at 15:48 , Torsten Mähne <t0...@gm...> wrote:

> Hello,
> 
> I think that I've run into the same segfault that has been reported on 20 Dec 2013 by JohnOldman <http://doxygen.10944.n7.nabble.com/Segfault-when-using-tag-files-from-documentation-that-has-been-compiled-using-tag-files-td6414.html#a6420>.
> 
> On 22 Dec 2013, 12:11:47, Dimitri van Heesch <doxygen@gm…> wrote:
>> On 22 Dec 2013, at 12:31, JohnOldman <j.r.greis@...> wrote:
>> 
>>> UPDATE:
>>> I've tried now with a whole bunch of different versions and it seems like
>>> the problem first arises as of 1.6.2:
>>> 1.6.1 and 1.6.0 work, 1.6.2 and about half a dozen other newer versions I've
>>> tried give me the same segfault. Could this be an incompatibility with my
>>> distribution? I'm using Scientific Linux 6.
> 
> I also observed the segfault on Scientific Linux 6 (RHEL 6 clone) on both, i686 and x86_64 platforms. I also have a situation, where I generate source code documentation for a library C, which depends in a chain on two other libraries B and A: C->B->A. I added the tag files generated by Doxygen for libraries B and A to the Doxyfile of library C.
> 
> When running doxygen on the Doxyfile of library C, the segfault happens always in the phase Adding xrefitems…
> 
> On my side, I don't observe the problem on doxygen 1.5.7.1 (Scientific Linux 5 i686).
> 
>> It is more likely a bug in doxygen introduced in 1.6.2 and triggered by your specific example.
>> Can you grab the latest doxygen source from GitHub and compile it using ./configure --debug and then run it from a debugger and/or from valgrind. 
>> That might give an indication where the problem is located.
> 
> I did clone the doxygen repository from Github (commit g3a5e6ac), build Doxygen with debug symbols as suggested and executed doxygen on the problematic Doxyfile from within gdb:
> 
> ------------------------------------------------------------------------
> 
> $ gdb ~/bin/doxygen
> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from ~/bin/doxygen...done.
> (gdb) run Doxyfile
> Starting program: ~/bin/doxygen Doxyfile
> [Thread debugging using libthread_db enabled]
> …
> Building group list...
> Building directory list...
> Building namespace list...
> Building file list...
> Building class list...
> Associating documentation with classes...
> Computing nesting relations for classes...
> Building example list...
> Searching for enumerations...
> Searching for documented typedefs...
> Searching for members imported via using declarations...
> Searching for included using directives...
> Searching for documented variables...
> Building interface member list...
> Building member list...
> Searching for friends...
> Searching for documented defines...
> Computing class inheritance relations...
> Computing class usage relations...
> Flushing cached template relations that have become invalid...
> Creating members for template instances...
> Computing class relations...
> Add enum values to enums...
> Searching for member function documentation...
> Building page list...
> Search for main page...
> Computing page relations...
> Determining the scope of groups...
> Sorting lists...
> Freeing entry tree
> Determining which enums are documented
> Computing member relations...
> Building full member lists recursively...
> Adding members to member groups.
> Computing member references...
> Inheriting documentation...
> Generating disk names...
> Adding source references...
> Adding xrefitems...
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000003275079367 in _int_malloc () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64 libgcc-4.4.6-4.el6.x86_64 libstdc++-4.4.6-4.el6.x86_64
> (gdb) bt full
> #0  0x0000003275079367 in _int_malloc () from /lib64/libc.so.6
> No symbol table info available.
> #1  0x000000327507a991 in malloc () from /lib64/libc.so.6
> No symbol table info available.
> #2  0x000000000043354f in QCString::duplicate (this=0x7fffff3ff130,
>    str=0x8b84fc "::") at ../qtools/qcstring.h:304
>        l = 2
> #3  0x000000000078e0ff in QCString::QCString (this=0x7fffff3ff130,
>    str=0x8b84fc "::") at scstring.cpp:61
> No locals.
> #4  0x00000000005c8f00 in getLanguageSpecificSeparator (lang=SrcLangExt_Unknown,
>    classScope=false) at util.cpp:7746
> No locals.
> #5  0x00000000006da326 in Definition::qualifiedName (this=0x1bfe150)
>    at definition.cpp:1358
> No locals.
> #6  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>    at definition.cpp:1358
> No locals.
> #7  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>    at definition.cpp:1358
> No locals.
> #8  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>    at definition.cpp:1358
> No locals.
> #9  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>    at definition.cpp:1358
> No locals.
> #10 0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>    at definition.cpp:1358
> No locals.
> [...]
> ------------------------------------------------------------------------
> 
> The backtrace continuous to mention Definition::qualifiedName thousands of times (I stopped after #10000).
> 
> ------------------------------------------------------------------------
> (gdb) up
> #1  0x000000327507a991 in malloc () from /lib64/libc.so.6
> (gdb)
> #2  0x000000000043354f in QCString::duplicate (this=0x7fffff3ff130,
>    str=0x8b84fc "::") at ../qtools/qcstring.h:304
> 304	    m_data = (char *)malloc(l+1);
> (gdb)
> #3  0x000000000078e0ff in QCString::QCString (this=0x7fffff3ff130,
>    str=0x8b84fc "::") at scstring.cpp:61
> 61	  duplicate(str);
> (gdb)
> #4  0x00000000005c8f00 in getLanguageSpecificSeparator (lang=SrcLangExt_Unknown,
>    classScope=false) at util.cpp:7746
> 7746	    return "::";
> (gdb)
> #5  0x00000000006da326 in Definition::qualifiedName (this=0x1bfe150)
>    at definition.cpp:1358
> 1358	           m_impl->localName;
> (gdb) print m_impl
> $1 = (DefinitionImpl *) 0x1bfe260
> (gdb) print m_impl->localName
> $2 = {m_data = 0x1c0eba0 "sc_in< sc_dt::sc_logic >"}
> ------------------------------------------------------------------------
> 
> This localName is from library A and is actually defined in a namespace called sc_core.
> 
> Looking at the recursive implementation of Definition::qualifiedName() in the mentioned source file, it seems that the end recursion criteria is never fulfilled:
> 
> ------------------------------------------------------------------------
> (gdb) l
> 1353	  }
> 1354	  else
> 1355	  {
> 1356	    m_impl->qualifiedName = m_impl->outerScope->qualifiedName()+
> 1357	           getLanguageSpecificSeparator(getLanguage())+
> 1358	           m_impl->localName;
> 1359	  }
> 1360	  //printf("end %s::qualifiedName()=%s\n",name().data(),m_impl->qualifiedName.data());
> 1361	  //count--;
> 1362	  return m_impl->qualifiedName;
> (gdb) print m_impl->outerScope->m_impl->qualifiedName
> $3 = {m_data = 0x0}
> ------------------------------------------------------------------------
> 
> Maybe something goes wrong with the lookup through the tag files?
> 
> I hope you have some suggestion how to fix the problem. I can help with testing a potential fix.
> 
>> Regards,
>>  Dimitri
> 
> Best regards,
> 
> Torsten
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck&#174;
> Code Sight&#153; - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] Segfault when using tag files from documentation that has been compiled using tag files

[Torsten M. <t0...@gm...>]

Hello,

I think that I've run into the same segfault that has been reported on 20 Dec 2013 by JohnOldman <http://doxygen.10944.n7.nabble.com/Segfault-when-using-tag-files-from-documentation-that-has-been-compiled-using-tag-files-td6414.html#a6420>.

On 22 Dec 2013, 12:11:47, Dimitri van Heesch <doxygen@gm…> wrote:
> On 22 Dec 2013, at 12:31, JohnOldman <j.r.greis@...> wrote:
> 
> > UPDATE:
> > I've tried now with a whole bunch of different versions and it seems like
> > the problem first arises as of 1.6.2:
> > 1.6.1 and 1.6.0 work, 1.6.2 and about half a dozen other newer versions I've
> > tried give me the same segfault. Could this be an incompatibility with my
> > distribution? I'm using Scientific Linux 6.

I also observed the segfault on Scientific Linux 6 (RHEL 6 clone) on both, i686 and x86_64 platforms. I also have a situation, where I generate source code documentation for a library C, which depends in a chain on two other libraries B and A: C->B->A. I added the tag files generated by Doxygen for libraries B and A to the Doxyfile of library C.

When running doxygen on the Doxyfile of library C, the segfault happens always in the phase Adding xrefitems…

On my side, I don't observe the problem on doxygen 1.5.7.1 (Scientific Linux 5 i686).

> It is more likely a bug in doxygen introduced in 1.6.2 and triggered by your specific example.
> Can you grab the latest doxygen source from GitHub and compile it using ./configure --debug and then run it from a debugger and/or from valgrind. 
> That might give an indication where the problem is located.

I did clone the doxygen repository from Github (commit g3a5e6ac), build Doxygen with debug symbols as suggested and executed doxygen on the problematic Doxyfile from within gdb:

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

$ gdb ~/bin/doxygen
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from ~/bin/doxygen...done.
(gdb) run Doxyfile
Starting program: ~/bin/doxygen Doxyfile
[Thread debugging using libthread_db enabled]
…
Building group list...
Building directory list...
Building namespace list...
Building file list...
Building class list...
Associating documentation with classes...
Computing nesting relations for classes...
Building example list...
Searching for enumerations...
Searching for documented typedefs...
Searching for members imported via using declarations...
Searching for included using directives...
Searching for documented variables...
Building interface member list...
Building member list...
Searching for friends...
Searching for documented defines...
Computing class inheritance relations...
Computing class usage relations...
Flushing cached template relations that have become invalid...
Creating members for template instances...
Computing class relations...
Add enum values to enums...
Searching for member function documentation...
Building page list...
Search for main page...
Computing page relations...
Determining the scope of groups...
Sorting lists...
Freeing entry tree
Determining which enums are documented
Computing member relations...
Building full member lists recursively...
Adding members to member groups.
Computing member references...
Inheriting documentation...
Generating disk names...
Adding source references...
Adding xrefitems...

Program received signal SIGSEGV, Segmentation fault.
0x0000003275079367 in _int_malloc () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64 libgcc-4.4.6-4.el6.x86_64 libstdc++-4.4.6-4.el6.x86_64
(gdb) bt full
#0  0x0000003275079367 in _int_malloc () from /lib64/libc.so.6
No symbol table info available.
#1  0x000000327507a991 in malloc () from /lib64/libc.so.6
No symbol table info available.
#2  0x000000000043354f in QCString::duplicate (this=0x7fffff3ff130,
    str=0x8b84fc "::") at ../qtools/qcstring.h:304
        l = 2
#3  0x000000000078e0ff in QCString::QCString (this=0x7fffff3ff130,
    str=0x8b84fc "::") at scstring.cpp:61
No locals.
#4  0x00000000005c8f00 in getLanguageSpecificSeparator (lang=SrcLangExt_Unknown,
    classScope=false) at util.cpp:7746
No locals.
#5  0x00000000006da326 in Definition::qualifiedName (this=0x1bfe150)
    at definition.cpp:1358
No locals.
#6  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
    at definition.cpp:1358
No locals.
#7  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
    at definition.cpp:1358
No locals.
#8  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
    at definition.cpp:1358
No locals.
#9  0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
    at definition.cpp:1358
No locals.
#10 0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
    at definition.cpp:1358
No locals.
[...]
------------------------------------------------------------------------

The backtrace continuous to mention Definition::qualifiedName thousands of times (I stopped after #10000).

------------------------------------------------------------------------
(gdb) up
#1  0x000000327507a991 in malloc () from /lib64/libc.so.6
(gdb)
#2  0x000000000043354f in QCString::duplicate (this=0x7fffff3ff130,
    str=0x8b84fc "::") at ../qtools/qcstring.h:304
304	    m_data = (char *)malloc(l+1);
(gdb)
#3  0x000000000078e0ff in QCString::QCString (this=0x7fffff3ff130,
    str=0x8b84fc "::") at scstring.cpp:61
61	  duplicate(str);
(gdb)
#4  0x00000000005c8f00 in getLanguageSpecificSeparator (lang=SrcLangExt_Unknown,
    classScope=false) at util.cpp:7746
7746	    return "::";
(gdb)
#5  0x00000000006da326 in Definition::qualifiedName (this=0x1bfe150)
    at definition.cpp:1358
1358	           m_impl->localName;
(gdb) print m_impl
$1 = (DefinitionImpl *) 0x1bfe260
(gdb) print m_impl->localName
$2 = {m_data = 0x1c0eba0 "sc_in< sc_dt::sc_logic >"}
------------------------------------------------------------------------

This localName is from library A and is actually defined in a namespace called sc_core.

Looking at the recursive implementation of Definition::qualifiedName() in the mentioned source file, it seems that the end recursion criteria is never fulfilled:

------------------------------------------------------------------------
(gdb) l
1353	  }
1354	  else
1355	  {
1356	    m_impl->qualifiedName = m_impl->outerScope->qualifiedName()+
1357	           getLanguageSpecificSeparator(getLanguage())+
1358	           m_impl->localName;
1359	  }
1360	  //printf("end %s::qualifiedName()=%s\n",name().data(),m_impl->qualifiedName.data());
1361	  //count--;
1362	  return m_impl->qualifiedName;
(gdb) print m_impl->outerScope->m_impl->qualifiedName
$3 = {m_data = 0x0}
------------------------------------------------------------------------

Maybe something goes wrong with the lookup through the tag files?

I hope you have some suggestion how to fix the problem. I can help with testing a potential fix.

> Regards,
>   Dimitri

Best regards,

Torsten

Re: [Doxygen-users] Fwd: Re: TAGFILES not working consistently in 1.8.7 (RHEL6)

[Keith R. <Kei...@ne...>]

Have to admit, I've never seen Doxygen crash for any reason! Recently our doxygen usage has seen us use many libraries all linked via tagfiles without any problem, so it doesn't sound like your problem is the same as our problem.

We don't use notitle so I don't think that's our problem either. We do however do something like:

\anchor mainpage_anchor
\mainpage Our Main Page

Maybe the anchor causes a problem somehow?

Keith

> -----Original Message-----
> From: Bernd Speiser [mailto:ber...@un...]
> Sent: 11 July 2014 07:54
> To: Dox...@li...
> Subject: [Doxygen-users] Fwd: Re: TAGFILES not working consistently in 1.8.7
> (RHEL6)
> 
> 
> 
> -------- Forwarded Message --------
> Subject: Re: [Doxygen-users] TAGFILES not working consistently in 1.8.7
> (RHEL6)
> Date: Wed, 09 Jul 2014 17:41:33 +0200
> From: Bernd Speiser <ber...@un...>
> Reply-To: ber...@un...
> To: joe...@el...
> 
> joe...@el... wrote:
> 
> Hi all,
> could this in any way be related to
> http://sourceforge.net/p/doxygen/mailman/message/31884753/ ?
> Here also three tag files are involved and cause a problem.
> Unfortunately, there never was any response the that problem report sent
> to the list on January 25, 2014. Maybe we can resolve this now? That would
> be great.
> 
> Best regards
> Bernd
> 
> > Hello Keith,
> >
> > we noticed the same problem here, after switching to 1.8.7. The reason
> > seams to be, that we use the option 'notitle' for the mainpage:
> > We have multiple libraries, that are linked together by .tag files.
> > Each library has a mainpage with 'notitle', and for each library we
> > get one of theses warnings.
> >
> > Best Regards,
> > Jörg
> >
> >
> >> Hi, we have just upgraded from 1.8.6 to 1.8.7 and appear to be having
> > an issue with TAGFILES
> >> since the upgrade. We have multiple source repositories with each one
> > generating their own
> >> documentation and their own tag file. We then link the documentation
> > by using the TAGFILES facility. E.g.
> >>
> >> Project A uses Project B tag file
> >>
> >> This worked fine in 1.8.6, but since moving to 1.8.7 certain
> >> (random?)
> > \ref links within Project
> >> A into Project B no longer work and we are seeing errors output from
> > doxygen like so:
> >>
> >> index:-1: warning: multiple use of section label 'index', (first
> > occurrence: index)
> >> /source/project-a/doc/mainpage.doxy:2: warning: multiple use of
> > section label 'index', (first
> >> occurrence: index)
> >>
> >> Interestingly though, if Project A is rebuilt using 1.8.7 but Project
> > B is not rebuilt using 1.8.
> >> 7 and left as a 1.8.6 build, the \ref links work fine. It is only
> >> when
> > Project B is also rebuilt
> >> using 1.8.7 that this happens.
> >>
> >> Any idea what is going on?
> >>
> >> Keith
> >
> > ----------------------------------------------
> > Setting Standards In Innovation
> > ----------------------------------------------
> >
> >
> >
> > ----------------------------------------------------------------------
> > -------- Open source business process management suite built on Java
> > and Eclipse Turn processes into business applications with Bonita BPM
> > Community Edition Quickly connect people, data, and systems into
> > organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> >
> >
> >
> > _______________________________________________
> > Doxygen-users mailing list
> > Dox...@li...
> > https://lists.sourceforge.net/lists/listinfo/doxygen-users
> >
> 
> 
> --
> ==========================================================
> =============
> Bernd Speiser
> Institut für Organische Chemie
> Auf der Morgenstelle 18
> D-72076 Tübingen
> Germany
> phone: +49-7071-2976205 (office) +49-7071-2972050 (laboratory)
>        +49-7071-2972098 (secretary)
> fax:   +49-7071-295518
> e-mail: ber...@un...
> Internet: http://www.uni-tuebingen.de/speiser
> ==========================================================
> =============
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community
> Edition Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] Fwd: Re: TAGFILES not working consistently in 1.8.7 (RHEL6)

[Bernd S. <ber...@un...>]

-------- Forwarded Message --------
Subject: Re: [Doxygen-users] TAGFILES not working consistently in 1.8.7
(RHEL6)
Date: Wed, 09 Jul 2014 17:41:33 +0200
From: Bernd Speiser <ber...@un...>
Reply-To: ber...@un...
To: joe...@el...

joe...@el... wrote:

Hi all,
could this in any way be related to
http://sourceforge.net/p/doxygen/mailman/message/31884753/ ?
Here also three tag files are involved and cause a problem.
Unfortunately, there never was any response the that problem report sent
to the list on January 25, 2014. Maybe we can resolve this now? That
would be great.

Best regards
Bernd

> Hello Keith,
> 
> we noticed the same problem here, after switching to 1.8.7. The reason
> seams to be, that we use the option 'notitle' for the mainpage:
> We have multiple libraries, that are linked together by .tag files. Each
> library has a mainpage with 'notitle', and for each library we get one
> of theses warnings.
> 
> Best Regards,
> Jörg
> 
> 
>> Hi, we have just upgraded from 1.8.6 to 1.8.7 and appear to be having
> an issue with TAGFILES
>> since the upgrade. We have multiple source repositories with each one
> generating their own
>> documentation and their own tag file. We then link the documentation
> by using the TAGFILES facility. E.g.
>>
>> Project A uses Project B tag file
>>
>> This worked fine in 1.8.6, but since moving to 1.8.7 certain (random?)
> \ref links within Project
>> A into Project B no longer work and we are seeing errors output from
> doxygen like so:
>>
>> index:-1: warning: multiple use of section label 'index', (first
> occurrence: index)
>> /source/project-a/doc/mainpage.doxy:2: warning: multiple use of
> section label 'index', (first
>> occurrence: index)
>>
>> Interestingly though, if Project A is rebuilt using 1.8.7 but Project
> B is not rebuilt using 1.8.
>> 7 and left as a 1.8.6 build, the \ref links work fine. It is only when
> Project B is also rebuilt
>> using 1.8.7 that this happens.
>>
>> Any idea what is going on?
>>
>> Keith
> 
> ----------------------------------------------
> Setting Standards In Innovation
> ----------------------------------------------
> 
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> 
> 
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 


-- 
=======================================================================
Bernd Speiser
Institut für Organische Chemie
Auf der Morgenstelle 18
D-72076 Tübingen
Germany
phone: +49-7071-2976205 (office) +49-7071-2972050 (laboratory)
       +49-7071-2972098 (secretary)
fax:   +49-7071-295518
e-mail: ber...@un...
Internet: http://www.uni-tuebingen.de/speiser
=======================================================================

Re: [Doxygen-users] TAGFILES not working consistently in 1.8.7 (RHEL6)

[<joe...@el...>]

Hello Keith,

we noticed the same problem here, after switching to 1.8.7. The reason 
seams to be, that we use the option 'notitle' for the mainpage:
We have multiple libraries, that are linked together by .tag files. Each 
library has a mainpage with 'notitle', and for each library we get one of 
theses warnings.

Best Regards,
Jörg


> Hi, we have just upgraded from 1.8.6 to 1.8.7 and appear to be having an 
issue with TAGFILES 
> since the upgrade. We have multiple source repositories with each one 
generating their own 
> documentation and their own tag file. We then link the documentation by 
using the TAGFILES facility. E.g.
> 
> Project A uses Project B tag file
> 
> This worked fine in 1.8.6, but since moving to 1.8.7 certain (random?) 
\ref links within Project 
> A into Project B no longer work and we are seeing errors output from 
doxygen like so:
> 
> index:-1: warning: multiple use of section label 'index', (first 
occurrence: index)
> /source/project-a/doc/mainpage.doxy:2: warning: multiple use of section 
label 'index', (first 
> occurrence: index)
> 
> Interestingly though, if Project A is rebuilt using 1.8.7 but Project B 
is not rebuilt using 1.8.
> 7 and left as a 1.8.6 build, the \ref links work fine. It is only when 
Project B is also rebuilt 
> using 1.8.7 that this happens.
> 
> Any idea what is going on?
> 
> Keith
---------------------------------------------- 
Setting Standards In Innovation 
---------------------------------------------- 

[Doxygen-users] General documentation usage, similar to doxygen.org

[Andne <an...@an...>]

I am trying to put together a collection of documentation for a project,
where a number of subprojects will be pulled together into a larger set of
documentation.  At the top level I want some general documentation that
doesn't come from any code.  I can create the pages fairly easily, but I
would like to customize the rest of the appearance as well and carry that on
to the subprojects.  I more or less understand how to use the custom
header/custom footers in html, but I've been looking at the doxygen
documentation some, and am getting confused since the files that the
documentation is generated from don't quite seem to match the site itself,
as well as I cannot find where some of the pages outside of the manual come
from, even though they appear to be generated by doxygen.

I have two questions:
Is the original source that the website is generated from available anywhere
online?
Are there custom scripts or something that run on the doxygen manual before
uploading it to the site that modify the generated files?  The site pages
don't seem to quite match the contents of the docs folder in git.

Thank you for your help.



--
View this message in context: http://doxygen.10944.n7.nabble.com/General-documentation-usage-similar-to-doxygen-org-tp6718.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.