doxygen-users — List for users of doxygen

[Doxygen-users] Classes being missed due to having # symbol in document.

[Jayty <ja...@su...>]

Apologies if this has already been asked, or if I'm asking a silly question
although I'm new to doxygen and must be missing something :)

So the issue I'm having is this. I'm using doxygen to produce documentation
for my Unity3D project, everything works well until I make use of unity's
code separation setup which involves using a tags throughout my documents to
separate server and client code.

For example - 

#if IsServer
server classes here,
#end if

#if IsClient
Client stuff here
#endif

The issue I'm having is that as soon as doxygen hits a #, it seems to avoid
the document in its entirety :/ I can't get around having to use the symbols
either since separating the server/client code into their own scripts is a
pain.

I'm sure I'm just missing the process to stop doxy having this behaviour,
any insight would be greatly appreciated.

Jay



--
View this message in context: http://doxygen.10944.n7.nabble.com/Classes-being-missed-due-to-having-symbol-in-document-tp7446.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] Doxygen not updating comments for duplicate files

[ansh2d87 <ans...@gm...>]

I am using doxygen to provide comments to some .c and .h files (file level
comments only). There are some files which are duplicated (same name) and
are present in different subfolders. So, when I provide comments for these
files, doxygen is not updating it in the generated html file.
I read doxygen command description provided at below link and tried
providing the path for such files to make them unique but that also not
working.
 
 http://www.doxygen.nl/commands.html#cmdfile 

The options I tried till now are as below. Consider, Nm.h is the file having
multiple copies:
 
 1.   /*! \file Nm.h
         * \brief Header file
       */
 2.   /*! \file \sgdcc\checkdrive\test\Nm.h
         * \brief Header file
       */
 3.   /*! \file sgdcc\checkdrive\test\Nm.h
         * \brief Header file
       */
 
Comments are not getting updated even for a single file. I tried providing
short path as well as full path but nothing is working. I am compliling
doxygen through ClearCase and the doxygen version used in it is 1.8.2

Please help me in resolving this issue.




--
View this message in context: http://doxygen.10944.n7.nabble.com/Doxygen-not-updating-comments-for-duplicate-files-tp7445.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] RES: doxygen build failure for Power8 because double free or corruption

[Jorge R. (IMAGO) <jr...@im...>]

I don't know the details but here are some thoughts to help:

Beware of m_queue.dequeue because it is not thread-safe, according to QT docs.

About "Since m_bufferNotEmpty has its own mutex internally, it should only allow one thread to be awaken", maybe it is not true, because the treads are awaken by wake or wakeAll methods. So, If we get two wake calls at the same time, we will have two threads ready to run. This situation should be avoided by the locker(&m_mutex) mutex, however.

I suggest to use a different mutex to control thread safety of the DotRunnerQueue::dequeue function and the bufferNotEmpty condition.

Regards,
Jorge Ramos

-----Mensagem original-----
De: Normand [mailto:no...@li...] 
Enviada em: segunda-feira, 2 de novembro de 2015 15:15
Para: Adrian M Negreanu <gr...@gm...>; Dimitri van Heesch <do...@gm...>
Cc: dox...@li...
Assunto: Re: [Doxygen-users] doxygen build failure for Power8 because double free or corruption



On 20/03/2015 23:24, Adrian M Negreanu wrote:
> Given that it's a power8 CPU (SMT), can this be triggered by an 
> instruction reordering somewhere in qwaitcondition_unix.cpp ? Maybe -O0 can help ?

I did a trial with -00 for all (not only qwaitcondition_unix.cpp) and it still failed.

> 
> Also valgrind, besides the fact that slows the execution, it also modifies the process instructions.
> 
> 
> On Thu, Mar 19, 2015 at 11:04 PM, Dimitri van Heesch <do...@gm... <mailto:do...@gm...>> wrote:
> 
>     Hi Normand,
> 
>     The issues seems to be in this piece of code:
> 
>     DotRunner *DotRunnerQueue::dequeue()
>     {
>       QMutexLocker locker(&m_mutex);
>       while (m_queue.isEmpty())
>       {
>         // wait until something is added to the queue
>         m_bufferNotEmpty.wait(&m_mutex);
>       }
>       DotRunner *result = m_queue.dequeue();
>       return result;
>     }
> 
>     It is one of the few areas that executed by multiple threads,
>     but it is protected by a mutex (under the hood the QMutex and QWaitCondition map to pthread calls).
>     Since m_bufferNotEmpty has its own mutex internally, it should only allow
>     one thread to be awaken. What you are seeing, it seems, is two threads doing a dequeue() simultaneously.
>     Would be nice if you could help me with debugging this issue.

I do not know how to debug this, adding printf do not help me to isolate a problem.
Any suggestions ?
===
     // wait until something is added to the queue
     m_bufferNotEmpty.wait(&m_mutex);
   }
+  pthread_t id = pthread_self();
+  printf("%08x: %p: DotRunnerQueue::dequeue, m_queue %p\n",id, this, 
+ m_queue);
   DotRunner *result = m_queue.dequeue();
   return result;
 }
===
...
ad0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
ac0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468 Running dot for graph 309/1586 Running dot for graph 310/1586
ac8df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468 Running dot for graph 311/1586
ab0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
ab8df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
ad0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468 Running dot for graph 312/1586 Running dot for graph 313/1586 Running dot for graph 314/1586
ac0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468 Running dot for graph 315/1586
ab0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
ac0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
ac8df190: 0x1002f8d0460: DotRunner
===

> 
>     A workaround is to set DOT_NUM_THREADS to 1.

The workaround is what is implemented today for openSUSE tumbleweed for ppc64le.

> 
>     Regards,
>       Dimitri
> 
>     > On 18 Mar 2015, at 12:45 , Normand <no...@li... <mailto:no...@li...>> wrote:
>     >
>     >
>     > On 11/03/2015 14:16, Normand wrote:
>     >> Hi there
>     >>
>     >> while building doxygen for opensuse on Power8 guest I hit a failure as detailed in (2)
>     >> The related backtrace extracted for core file is appended below in (1)
>     >>
>     >>
>     >> === (1)
>     >> Core was generated by `./bin/doxygen '.
>     >> Program terminated with signal SIGABRT, Aborted.
>     >> #0  0x00003fffa5acd194 in __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:55
>     >> 55      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>     >> Missing separate debuginfos, use: zypper install libgcc_s1-debuginfo-4.8.3+r218481-2.1.ppc64le libstdc++6-debuginfo-4.8.3+r218481-2.1.ppc64le
>     >> (gdb) bt
>     >> #0  0x00003fffa5acd194 in __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:55
>     >> #1  0x00003fffa5acf184 in __GI_abort () at abort.c:78
>     >> #2  0x00003fffa5b136c4 in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:175
>     >> #3  0x00003fffa5b1ba84 in malloc_printerr (action=<optimized out>, str=0x3fffa5c06b50 "double free or corruption (fasttop)", ptr=<optimized out>) at malloc.c:4960
>     >> #4  0x00003fffa5b1cadc in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>) at malloc.c:3831
>     >> #5  0x00003fffa5dece10 in operator delete(void*) () from /usr/lib64/libstdc++.so.6
>     >> #6  0x00000000106620e4 in QGList::takeFirst (this=<optimized out>) at qglist.cpp:628
>     >> #7  0x000000001053ba84 in dequeue (this=<optimized out>) at ../qtools/qqueue.h:59
>     >> #8  DotRunnerQueue::dequeue (this=0x1001910fcc0) at dot.cpp:1170
>     >> #9  0x000000001053bb18 in DotWorkerThread::run (this=0x10019112a50) at dot.cpp:1191
>     >> #10 0x00000000106a0a44 in QThreadPrivate::start (arg=0x10019112a50) at qthread_unix.cpp:87
>     >> #11 0x00003fffa5ee9454 in start_thread (arg=0x3fffa38bf180) at pthread_create.c:335
>     >> #12 0x00003fffa5b9e0c4 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:96
>     >> ===
>     >>
>     >> (2) https://bugzilla.suse.com/show_bug.cgi?id=921577
>     >>
>     >
>     >
>     >
>     > I was able to recreate the problem with doxygen last git commit 1c8bbb6
>     > *   1c8bbb6 (HEAD, origin/master, origin/HEAD, master) Merge pull request #314
>     >
>     > The associated backtrace (from core file) only differ from above by some line numbers
>     > But is still pointing to same call sequence:
>     > from DotWorkerThread::run
>     > to delete in QCollection::Item QGList::takeFirst
>     > ===
>     > #0  0x00003fff8433d194 in raise () from /lib64/libc.so.6
>     > Missing separate debuginfos, use: zypper install glibc-debuginfo-2.21-3.3.ppc64le libgcc_s1-debuginfo-4.8.3+r218481-4.3.ppc64le libstdc++6-debuginfo-4.8.3+r218481-4.3.ppc64le
>     > (gdb) bt
>     > #0  0x00003fff8433d194 in raise () from /lib64/libc.so.6
>     > #1  0x00003fff8433f184 in abort () from /lib64/libc.so.6
>     > #2  0x00003fff843836c4 in __libc_message () from /lib64/libc.so.6
>     > #3  0x00003fff8438ba84 in malloc_printerr () from /lib64/libc.so.6
>     > #4  0x00003fff8438cadc in _int_free () from /lib64/libc.so.6
>     > #5  0x00003fff8465ce10 in operator delete(void*) () from /usr/lib64/libstdc++.so.6
>     > #6  0x000000001066c5e4 in QGList::takeFirst (this=<optimized out>) at qglist.cpp:628
>     > #7  0x0000000010544e04 in dequeue (this=<optimized out>) at ../qtools/qqueue.h:59
>     > #8  DotRunnerQueue::dequeue (this=0x1001707f7b0) at dot.cpp:1181
>     > #9  0x0000000010544e98 in DotWorkerThread::run (this=0x1001707efd0) at dot.cpp:1202
>     > #10 0x00000000106aaf44 in QThreadPrivate::start (arg=0x1001707efd0) at qthread_unix.cpp:87
>     > #11 0x00003fff84759454 in start_thread () from /lib64/libpthread.so.0
>     > #12 0x00003fff8440e0c4 in clone () from /lib64/libc.so.6
>     > ===
>     >
>     > The occurence is timing dependent, and there is no failure if trying to start doxygen via gdb or valgrind,
>     > so I do not know how to continue investigation.
>     >
>     > any suggestions are welcome.
>     >
>     > ---
>     > Michel Normand
>     >


--
Michel Normand


------------------------------------------------------------------------------
_______________________________________________
Doxygen-users mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] doxygen build failure for Power8 because double free or corruption

[Normand <no...@li...>]

On 20/03/2015 23:24, Adrian M Negreanu wrote:
> Given that it's a power8 CPU (SMT), can this be triggered by an instruction reordering
> somewhere in qwaitcondition_unix.cpp ? Maybe -O0 can help ?

I did a trial with -00 for all (not only qwaitcondition_unix.cpp) and it still failed.

> 
> Also valgrind, besides the fact that slows the execution, it also modifies the process instructions.
> 
> 
> On Thu, Mar 19, 2015 at 11:04 PM, Dimitri van Heesch <do...@gm... <mailto:do...@gm...>> wrote:
> 
>     Hi Normand,
> 
>     The issues seems to be in this piece of code:
> 
>     DotRunner *DotRunnerQueue::dequeue()
>     {
>       QMutexLocker locker(&m_mutex);
>       while (m_queue.isEmpty())
>       {
>         // wait until something is added to the queue
>         m_bufferNotEmpty.wait(&m_mutex);
>       }
>       DotRunner *result = m_queue.dequeue();
>       return result;
>     }
> 
>     It is one of the few areas that executed by multiple threads,
>     but it is protected by a mutex (under the hood the QMutex and QWaitCondition map to pthread calls).
>     Since m_bufferNotEmpty has its own mutex internally, it should only allow
>     one thread to be awaken. What you are seeing, it seems, is two threads doing a dequeue() simultaneously.
>     Would be nice if you could help me with debugging this issue.

I do not know how to debug this, adding printf do not help me to isolate a problem.
Any suggestions ?
===
     // wait until something is added to the queue
     m_bufferNotEmpty.wait(&m_mutex);
   }
+  pthread_t id = pthread_self();
+  printf("%08x: %p: DotRunnerQueue::dequeue, m_queue %p\n",id, this, m_queue);
   DotRunner *result = m_queue.dequeue();
   return result;
 }
===
...
ad0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
ac0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
Running dot for graph 309/1586
Running dot for graph 310/1586
ac8df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
Running dot for graph 311/1586
ab0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
ab8df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
ad0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
Running dot for graph 312/1586
Running dot for graph 313/1586
Running dot for graph 314/1586
ac0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
Running dot for graph 315/1586
ab0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
ac0df190: 0x1002f8d0460: DotRunnerQueue::dequeue, m_queue 0x1002f8d0468
ac8df190: 0x1002f8d0460: DotRunner
===

> 
>     A workaround is to set DOT_NUM_THREADS to 1.

The workaround is what is implemented today for openSUSE tumbleweed for ppc64le.

> 
>     Regards,
>       Dimitri
> 
>     > On 18 Mar 2015, at 12:45 , Normand <no...@li... <mailto:no...@li...>> wrote:
>     >
>     >
>     > On 11/03/2015 14:16, Normand wrote:
>     >> Hi there
>     >>
>     >> while building doxygen for opensuse on Power8 guest I hit a failure as detailed in (2)
>     >> The related backtrace extracted for core file is appended below in (1)
>     >>
>     >>
>     >> === (1)
>     >> Core was generated by `./bin/doxygen '.
>     >> Program terminated with signal SIGABRT, Aborted.
>     >> #0  0x00003fffa5acd194 in __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:55
>     >> 55      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>     >> Missing separate debuginfos, use: zypper install libgcc_s1-debuginfo-4.8.3+r218481-2.1.ppc64le libstdc++6-debuginfo-4.8.3+r218481-2.1.ppc64le
>     >> (gdb) bt
>     >> #0  0x00003fffa5acd194 in __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:55
>     >> #1  0x00003fffa5acf184 in __GI_abort () at abort.c:78
>     >> #2  0x00003fffa5b136c4 in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:175
>     >> #3  0x00003fffa5b1ba84 in malloc_printerr (action=<optimized out>, str=0x3fffa5c06b50 "double free or corruption (fasttop)", ptr=<optimized out>) at malloc.c:4960
>     >> #4  0x00003fffa5b1cadc in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>) at malloc.c:3831
>     >> #5  0x00003fffa5dece10 in operator delete(void*) () from /usr/lib64/libstdc++.so.6
>     >> #6  0x00000000106620e4 in QGList::takeFirst (this=<optimized out>) at qglist.cpp:628
>     >> #7  0x000000001053ba84 in dequeue (this=<optimized out>) at ../qtools/qqueue.h:59
>     >> #8  DotRunnerQueue::dequeue (this=0x1001910fcc0) at dot.cpp:1170
>     >> #9  0x000000001053bb18 in DotWorkerThread::run (this=0x10019112a50) at dot.cpp:1191
>     >> #10 0x00000000106a0a44 in QThreadPrivate::start (arg=0x10019112a50) at qthread_unix.cpp:87
>     >> #11 0x00003fffa5ee9454 in start_thread (arg=0x3fffa38bf180) at pthread_create.c:335
>     >> #12 0x00003fffa5b9e0c4 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:96
>     >> ===
>     >>
>     >> (2) https://bugzilla.suse.com/show_bug.cgi?id=921577
>     >>
>     >
>     >
>     >
>     > I was able to recreate the problem with doxygen last git commit 1c8bbb6
>     > *   1c8bbb6 (HEAD, origin/master, origin/HEAD, master) Merge pull request #314
>     >
>     > The associated backtrace (from core file) only differ from above by some line numbers
>     > But is still pointing to same call sequence:
>     > from DotWorkerThread::run
>     > to delete in QCollection::Item QGList::takeFirst
>     > ===
>     > #0  0x00003fff8433d194 in raise () from /lib64/libc.so.6
>     > Missing separate debuginfos, use: zypper install glibc-debuginfo-2.21-3.3.ppc64le libgcc_s1-debuginfo-4.8.3+r218481-4.3.ppc64le libstdc++6-debuginfo-4.8.3+r218481-4.3.ppc64le
>     > (gdb) bt
>     > #0  0x00003fff8433d194 in raise () from /lib64/libc.so.6
>     > #1  0x00003fff8433f184 in abort () from /lib64/libc.so.6
>     > #2  0x00003fff843836c4 in __libc_message () from /lib64/libc.so.6
>     > #3  0x00003fff8438ba84 in malloc_printerr () from /lib64/libc.so.6
>     > #4  0x00003fff8438cadc in _int_free () from /lib64/libc.so.6
>     > #5  0x00003fff8465ce10 in operator delete(void*) () from /usr/lib64/libstdc++.so.6
>     > #6  0x000000001066c5e4 in QGList::takeFirst (this=<optimized out>) at qglist.cpp:628
>     > #7  0x0000000010544e04 in dequeue (this=<optimized out>) at ../qtools/qqueue.h:59
>     > #8  DotRunnerQueue::dequeue (this=0x1001707f7b0) at dot.cpp:1181
>     > #9  0x0000000010544e98 in DotWorkerThread::run (this=0x1001707efd0) at dot.cpp:1202
>     > #10 0x00000000106aaf44 in QThreadPrivate::start (arg=0x1001707efd0) at qthread_unix.cpp:87
>     > #11 0x00003fff84759454 in start_thread () from /lib64/libpthread.so.0
>     > #12 0x00003fff8440e0c4 in clone () from /lib64/libc.so.6
>     > ===
>     >
>     > The occurence is timing dependent, and there is no failure if trying to start doxygen via gdb or valgrind,
>     > so I do not know how to continue investigation.
>     >
>     > any suggestions are welcome.
>     >
>     > ---
>     > Michel Normand
>     >


-- 
Michel Normand

Re: [Doxygen-users] Asterisks not eliminated in @code

[Yongwei Wu <wuy...@gm...>]

On 27 October 2015 at 02:51, Dimitri van Heesch <do...@gm...> wrote:
>
> Hi Yongwei,
>
> > On 26 Oct 2015, at 14:39 , Yongwei Wu <wuy...@gm...> wrote:
> >
> > I have some doc comments that work well in v1.6 or earlier:
> >
> > /**
> >  * Functor to return objects pointed by a container of pointers.
> >  *
> >  * A typical usage might be like:
> >  * @code
> >  * vector<Object*> v;
> >  * ...
> >  * transform(v.begin(), v.end(),
> >  *           ostream_iterator<Object>(cout, " "),
> >  *           dereference());
> >  * @endcode
> >  */
> >
> > The generated documentation eliminates all the beginning asterisks automatically, as can be seen here:
> >
> > http://nvwa.sourceforge.net/doc/1.0/structnvwa_1_1dereference.html
> >
> > I have found the behaviour changed in v1.8: currently the generated documentation keeps the asterisks between @code and @endcode. The generated code looks like this:
> > Functor to delete objects pointed by a container of pointers.
> >
> > A typical usage might be like:
> >
> > * list<Object*> l;
> > * ...
> > * for_each(l.begin(), l.end(), delete_object());
> > *
> >
> > Is this a bug or intentional change?
>
> It was a bug in version 1.8.5 only. No other 1.8.x version has this issue.

Oops, really sorry for not testing against the latest version.

I can confirm now that 1.8.10 does not have this issue.

Best regards,

Yongwei

-- 
Wu Yongwei
URL: http://wyw.dcweb.cn/

Re: [Doxygen-users] Asterisks not eliminated in @code

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

Hi Yongwei,

> On 26 Oct 2015, at 14:39 , Yongwei Wu <wuy...@gm...> wrote:
> 
> I have some doc comments that work well in v1.6 or earlier:
> 
> /**
>  * Functor to return objects pointed by a container of pointers.
>  *
>  * A typical usage might be like:
>  * @code
>  * vector<Object*> v;
>  * ...
>  * transform(v.begin(), v.end(),
>  *           ostream_iterator<Object>(cout, " "),
>  *           dereference());
>  * @endcode
>  */
> 
> The generated documentation eliminates all the beginning asterisks automatically, as can be seen here:
> 
> http://nvwa.sourceforge.net/doc/1.0/structnvwa_1_1dereference.html
> 
> I have found the behaviour changed in v1.8: currently the generated documentation keeps the asterisks between @code and @endcode. The generated code looks like this:
> Functor to delete objects pointed by a container of pointers.
> 
> A typical usage might be like:
> 
> * list<Object*> l;
> * ...
> * for_each(l.begin(), l.end(), delete_object());
> * 
> 
> Is this a bug or intentional change?

It was a bug in version 1.8.5 only. No other 1.8.x version has this issue.

Regards,
  Dimitri

[Doxygen-users] Asterisks not eliminated in @code

[Yongwei Wu <wuy...@gm...>]

I have some doc comments that work well in v1.6 or earlier:

/**
 * Functor to return objects pointed by a container of pointers.
 *
 * A typical usage might be like:
 * @code
 * vector<Object*> v;
 * ...
 * transform(v.begin(), v.end(),
 *           ostream_iterator<Object>(cout, " "),
 *           dereference());
 * @endcode
 */

The generated documentation eliminates all the beginning asterisks
automatically, as can be seen here:

http://nvwa.sourceforge.net/doc/1.0/structnvwa_1_1dereference.html

I have found the behaviour changed in v1.8: currently the generated
documentation keeps the asterisks between @code and @endcode. The generated
code looks like this:

Functor to delete objects pointed by a container of pointers.

A typical usage might be like:
* list<Object*> l;
* ...
* for_each(l.begin(), l.end(), delete_object());
*

Is this a bug or intentional change?

I would appreciate the original behaviour better.

Best regards,

Yongwei

-- 
Wu Yongwei
URL: http://wyw.dcweb.cn/

[Doxygen-users] Call graph in C language

[bennasr <mo....@gm...>]

I'm using doxgygen to generate Call graph for C file, i noticed that doxygen
generates the same call graph for header file(*.h) and for c file (*.c)
My question is why doxgygen duplicate call graph for function, ones for *.H
file and ones for  *.C file?
Call graph for *.H file is duplicated and not needed, is there a way to get
around and generate call graph only for *.C file?

example:
=====call graph for H file======
digraph "Function_init"
{
  edge
[fontname="Helvetica",fontsize="10",labelfontname="Helvetica",labelfontsize="10"];
  node [fontname="Helvetica",fontsize="10",shape=record];
  rankdir="LR";
  Node1 [label="Function_init",height=0.2,width=0.4,color="black",
fillcolor="grey75", style="filled", fontcolor="black"];
  Node1 -> Node2
[color="midnightblue",fontsize="10",style="solid",fontname="Helvetica"];
  Node2 [label="Function_RstSw",height=0.2,width=0.4,color="black",
fillcolor="white",..."];
}
=====call graph for C file======
digraph "Function_init"
{
  edge
[fontname="Helvetica",fontsize="10",labelfontname="Helvetica",labelfontsize="10"];
  node [fontname="Helvetica",fontsize="10",shape=record];
  rankdir="LR";
  Node1 [label="Function_init",height=0.2,width=0.4,color="black",
fillcolor="grey75", style="filled", fontcolor="black"];
  Node1 -> Node2
[color="midnightblue",fontsize="10",style="solid",fontname="Helvetica"];
  Node2 [label="Function_RstSw",height=0.2,width=0.4,color="black",
fillcolor="white", .."];
}




--
View this message in context: http://doxygen.10944.n7.nabble.com/Call-graph-in-C-language-tp7439.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] Call graph in C language

[bennasr <mo....@gm...>]

I'm using doxgygen to generate Call graph for C file, i noticed that doxygen
generates the same call graph for header file(*.h) and for c file (*.c)
My question is why doxgygen duplicate call graph for function, ones for *.H
file and ones for  *.C file?
Call graph for *.H file is duplicated and not needed, is there a way to get
around and generate call graph only for *.C file?

example:
=====call graph for H file======
digraph "Function_init"
{
  edge
[fontname="Helvetica",fontsize="10",labelfontname="Helvetica",labelfontsize="10"];
  node [fontname="Helvetica",fontsize="10",shape=record];
  rankdir="LR";
  Node1 [label="Function_init",height=0.2,width=0.4,color="black",
fillcolor="grey75", style="filled", fontcolor="black"];
  Node1 -> Node2
[color="midnightblue",fontsize="10",style="solid",fontname="Helvetica"];
  Node2 [label="Function_RstSw",height=0.2,width=0.4,color="black",
fillcolor="white",..."];
}
=====call graph for C file======
digraph "Function_init"
{
  edge
[fontname="Helvetica",fontsize="10",labelfontname="Helvetica",labelfontsize="10"];
  node [fontname="Helvetica",fontsize="10",shape=record];
  rankdir="LR";
  Node1 [label="Function_init",height=0.2,width=0.4,color="black",
fillcolor="grey75", style="filled", fontcolor="black"];
  Node1 -> Node2
[color="midnightblue",fontsize="10",style="solid",fontname="Helvetica"];
  Node2 [label="Function_RstSw",height=0.2,width=0.4,color="black",
fillcolor="white", .."];
}




--
View this message in context: http://doxygen.10944.n7.nabble.com/Call-graph-in-C-language-tp7438.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] Callgraphs and imported functions in python

[bennasr <mo....@gm...>]

I have tested call graph on C file,i guess doxygen can't generate a call
graph for function witch is not already defined.
As you see in your example, when you define function_a and function_b,
doxygen generate a call graph for function() that includes both a and b.



--
View this message in context: http://doxygen.10944.n7.nabble.com/Callgraphs-and-imported-functions-in-python-tp7433p7437.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] document parser in BNF

[Nicolas B. <nic...@gm...>]

Hi list,

I am trying to document a parser using BNF format. What I am trying to
achieve is something like this:

https://docs.python.org/3.4/reference/compound_stmts.html

In other words I would like to add boxes with a three column table

<expr>  | ::= | <expr1>
<expr1> | ::= | <expr2>

and would like to be able to link <expr*> on the right hand side to
corresponding <expr*> on the left hand side. I haven't found a good
solution though. Doxygen doesn't seem to support header-less tables,
nor custom anchors other than bare html anchors.

Any suggestions would be greatly appreciated.

Thanks,

Nick

Re: [Doxygen-users] plugin / filter not behaving as expected

[Albert <alb...@gm...>]

I've just pushed an update to github (pull request 404) with an extra note
in the Doxyfile / documentation

On Mon, Oct 12, 2015 at 11:01 AM, Clayton <cla...@gm...> wrote:

> Hi Albert,
>
> On Sat, 10 Oct 2015 10:31:07 +0200
> Albert <alb...@gm...> wrote:
>
> > I assume you caught the output of the perl script into a cpp fie and
> > tried to process that with doxygen and this is working.
>
> Yes indeed, that worked and works.
>
> > One thing that comes quickly  into my mind is: is EXTENSION_MAPPING
> > set so that css file are handled as cpp files?
>
> Bingo! That is the missing piece. And I think that was also the problem
> in my e-mail of some time ago about issues with Visual Basic as well.
> This explains a lot. Thanks a lot for the suggestion!!!
>
> > (see the output of the doxygen command if the css files are listed in
> > the files processed)
>
> They actually were being listed as being parsed, ie.
>
>         Parsing files
>         Reading /tmp/temp/syntax.css...
>
> Even with EXTENSION_MAPPING undefined. And then nothing happened, no
> errors either, which was confusing.
>
> Thanks again,
> Clayton
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

[Doxygen-users] Fortan problems

[Petr P. <pet...@se...>]

Hi all,

It seems Doxygen 1.8.10 does not work properly on Fortran modules.

A. If a module is not documented it is not listed on the "file 
reference" page (as expected) but all its functions/variables are (bug!).

B. If EXTRACT_PRIVATE = NO, module private functions are not listed (as 
expected) but module private variables are (bug!).

C. Implicit PRIVATE/PUBLIC/PROTECTED statements in a module work as 
expected but are not "appended" to function/variable documentation. This 
is only a nuisance.

D. If a documented function (inside or outside a module) is followed by 
one or more undocumented functions, the function calls in the following 
undocumented functions are listed in "References" of the documented 
function (bug!).

Could this issues be adressed in the next version? Thanks :)

Best regards,

Petr

[Doxygen-users] Callgraphs and imported functions in python

[Fabian N. <fab...@sc...>]

Hi everyone,

We're documenting a Python code with doxygen and have just made the 
following observation; Our file looks something like

#! /usr/bin/python3
"""
Comment block
"""
import foo

def main():
	...
	foo.bar()

Now the call graph of main() doesn't show foo.bar; However if we write
from foo import bar
then it does (as I would expect).


On the other hand, we tried to write another 'minimal example':
==== function.py ====


import a
import b

def function():
    a.function_a()
    b.function_b("HELLO B")



function()
=====================

==== a.py ===========

def function_a():
    print("Function A")
=====================

==== b.py ===========

def function_b(a):
    print(a)
=====================

 From these three files, Doxygen generates a call graph for function() 
that includes both a and b, although we only used the global import 
statement.

Does anyone know why it's not working as expected in our original case?

Cheers,
Fabian.

Re: [Doxygen-users] plugin / filter not behaving as expected

[Clayton <cla...@gm...>]

Hi Albert,

On Sat, 10 Oct 2015 10:31:07 +0200
Albert <alb...@gm...> wrote:

> I assume you caught the output of the perl script into a cpp fie and
> tried to process that with doxygen and this is working.

Yes indeed, that worked and works.

> One thing that comes quickly  into my mind is: is EXTENSION_MAPPING
> set so that css file are handled as cpp files?

Bingo! That is the missing piece. And I think that was also the problem
in my e-mail of some time ago about issues with Visual Basic as well.
This explains a lot. Thanks a lot for the suggestion!!!

> (see the output of the doxygen command if the css files are listed in
> the files processed)

They actually were being listed as being parsed, ie.

	Parsing files
	Reading /tmp/temp/syntax.css...

Even with EXTENSION_MAPPING undefined. And then nothing happened, no
errors either, which was confusing.

Thanks again,
Clayton

[Doxygen-users] Whether I can generate C++/CX API doc via doxygen?

[Heefan <he...@gm...>]

Hi all,

I am working on Windows Phone programming in C++/CX which is Windows
Runtime stuff, like C++/CLI in .NET framework.
I tried to use doxygen to generate API document but failed, what I can
think out is the C++/CX syntax cannot be recognized by doxygen.

I have tried many plugins on Visual Studio as well, it seems lack support
for C++/CX.  I also generate XML files from Visual Studio,but the one is
not user-friendly.
As I am very new on Windows Platform, I am afraid I missed something, and
looking forward replying from doxygen users,  whether I can generate C++/CX
API doc via doxygen?

Thanks & Regards

Re: [Doxygen-users] plugin / filter not behaving as expected

[Albert <alb...@gm...>]

Clayton,

I assume you caught the output of the perl script into a cpp fie and tried
to process that with doxygen and this is working.
One thing that comes quickly  into my mind is: is EXTENSION_MAPPING set so
that css file are handled as cpp files?
(see the output of the doxygen command if the css files are listed in the
files processed)

Albert

On Sat, Oct 10, 2015 at 9:40 AM, Clayton <cla...@gm...> wrote:

> Hi all,
>
> I am prototyping a plugin a la
>
>         http://www.stack.nl/~dimitri/doxygen/helpers.html
>
> for html / js / css (GitHub repos tagged as "html") to use Doxygen to
> analyze certain aspects of this kind of code. As a for-instance,
> attached is an actual syntax.css file pulled from a repo, and the
> corresponding syntax.cpp output after I pass it through my filter. g++
> reports no syntax issues with syntax.cpp, and Doxygen, with a default
> Doxyfile, processes syntax.cpp and produces a list of classes as
> expected.
>
> BUT.... If I configure Doxyfile with my css filter:
>
>         INPUT_FILTER = /path/to/plugins/webplugin/web2doxy.pl
>         FILE_PATTERNS = *.css
>
> absolutely nothing happens. No output, no errors, nothing. (Note that I
> have already seen this working sometimes with some other filters built
> by other people.)
>
> Any ideas about what might be missing in my simple configuration above?
> Assuming Doxygen is presenting syntax.css to stdin of my filter
> unmodified, the filter should be giving Doxygen back exactly the
> content of syntax.cpp on it's stdout.
>
> But why the different behavior?
>
> Thanks for any insights,
> Clayton
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

[Doxygen-users] plugin / filter not behaving as expected

[Clayton <cla...@gm...>]

Hi all,

I am prototyping a plugin a la

	http://www.stack.nl/~dimitri/doxygen/helpers.html

for html / js / css (GitHub repos tagged as "html") to use Doxygen to
analyze certain aspects of this kind of code. As a for-instance,
attached is an actual syntax.css file pulled from a repo, and the
corresponding syntax.cpp output after I pass it through my filter. g++
reports no syntax issues with syntax.cpp, and Doxygen, with a default
Doxyfile, processes syntax.cpp and produces a list of classes as
expected.

BUT.... If I configure Doxyfile with my css filter:

	INPUT_FILTER = /path/to/plugins/webplugin/web2doxy.pl
	FILE_PATTERNS = *.css

absolutely nothing happens. No output, no errors, nothing. (Note that I
have already seen this working sometimes with some other filters built
by other people.)

Any ideas about what might be missing in my simple configuration above?
Assuming Doxygen is presenting syntax.css to stdin of my filter
unmodified, the filter should be giving Doxygen back exactly the
content of syntax.cpp on it's stdout.

But why the different behavior?

Thanks for any insights,
Clayton

Re: [Doxygen-users] Inline code does not render the same with 1.8.4 and 1.8.10

[Olivier C. <Oli...@ce...>]

any idea about this one ?

On 07 Oct 2015, at 16:00, Olivier Couet <oli...@ce...<mailto:oli...@ce...>> wrote:

Hi,

I have the following comments in my code:

///
/// ### Example1 of use of exec1.C
/// ~~~ {.cpp}
///  Root > TFile f("hsimple.root")
///  Root > hpx.Draw()
///  Root > c1.AddExec("ex1",".x exec1.C")
/// ~~~
///

with 1.8.4 it renders the following way:

<1.8.4.png>

with 1.8.10 it renders like that:

<1.8.10.png>

:-( :-( …… what should I do ?

Thanks,
Olivier

Re: [Doxygen-users] Inline code does not render the same with 1.8.4 and 1.8.10

[Stefan P. <ste...@gm...>]

Am 07.10.2015 um 16:00 schrieb Olivier Couet:
> Hi,
>
> I have the following comments in my code:
>
> ///
> /// ### Example1 of use of exec1.C
> /// ~~~ {.cpp}
> ///  Root > TFile f("hsimple.root")
> ///  Root > hpx.Draw()
> ///  Root > c1.AddExec("ex1",".x exec1.C")
> /// ~~~
> ///
>

Have you set "MARKDOWN_SUPPORT = YES" in you configuration file?


-- 
*Stefan P.*

Top-posting:
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[Doxygen-users] Inline code does not render the same with 1.8.4 and 1.8.10

[Olivier C. <Oli...@ce...>]

Hi,

I have the following comments in my code:

///
/// ### Example1 of use of exec1.C
/// ~~~ {.cpp}
///  Root > TFile f("hsimple.root")
///  Root > hpx.Draw()
///  Root > c1.AddExec("ex1",".x exec1.C")
/// ~~~
///

with 1.8.4 it renders the following way:

[cid:0BACE03D-A928-4A22-8896-85551E5FD973]

with 1.8.10 it renders like that:

[cid:B8E59074-9D91-44D7-AC91-8BB98EB5E035]

:-( :-( …… what should I do ?

Thanks,
Olivier

[Doxygen-users] Internal inconsistency scope for class not found with .tag file

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

Doxygen 1.8.10
Library A uses a .tag file from Library B
When I generate the documentation for Library A, I get the following type of
warning:
LibraryB/LibraryB.tags:1: warning: Internal inconsistency: scope for class
namespaceX::namespaceY::ClassX::SubclassX::StructX not found!

Note that when I generate the documentation for Library B, I do not see any
warning or error messages related to
namespaceX::namespaceY::ClassX::SubclassX::StructX 

What could be causing this type of warning ?




--
View this message in context: http://doxygen.10944.n7.nabble.com/Internal-inconsistency-scope-for-class-not-found-with-tag-file-tp7425.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] It seems Doxygen get confuse when using

[Albert <alb...@gm...>]

Olivier,

Which version of doxygen are you using?
Can you provide a small project (the 3 source files and the used Doxyfile)
to reproduce the problem?

Albert

On Wed, Sep 30, 2015 at 8:53 AM, Olivier Couet <Oli...@ce...>
wrote:

> Any idea about this one ?
>
>
> On 28 Sep 2015, at 08:28, Olivier Couet <oli...@ce...> wrote:
>
> Hi,
>
> We have a C++ class called: *TFile*
>
> The C++ source file is in:* /roottrunk/io/io/src/TFile.cxx*
> The header is in :              */roottrunk/io/io/inc/TFile.h*
>
> We have also an extra  TFile.h in: */roottrunk/io/io/v7/inc/ROOT/TFile.h*
>
>
> *STRIP_FROM_INC_PATH* is left blank (in *Doxyfile*), we get the following
> lines a the end of the file *classTFile.html*
> generated by doxygen:
>
> ------
> The documentation for this class was generated from the following files:
>
>    - io/io/inc/TFile.h
>    - io/io/src/TFile.cxx
>
> ------
>
> If instead we put the following paths in *STRIP_FROM_INC_PATH *(in
> *Doxyfile*)
>
> */roottrunk/io/io/inc*
> */roottrunk/io/io/v7/inc*
>
> we get the following lines a the end of the file *classTFile.html *generated
> by doxygen
>
> ------
> The documentation for this class was generated from the following files:
>
>    - io/io/v7/inc/ROOT/TFile.h
>    - io/io/src/TFile.cxx
>
> ------
>
> so it seems doxygen gets confused and pick the wrong include file.
>
> Can you explain ?
>
> Cheers, Olivier
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

[Doxygen-users] Fortran module private variables and EXTRACT_PRIVATE = NO

[Petr P. <pet...@se...>]

Hi all,

I have Doxygen 1.8.10 and a Fortran project. It seems the 
EXTRACT_PRIVATE = NO config option only "hides" module private 
functions/subroutines but not module private variables. Isn't that a bug?

I'm including a minimum working test. Thanks for any comments.

Best regards,

Petr

Re: [Doxygen-users] RTF output has incomplete "References" and "Referenced by" sections

[Ingolf S. <ing...@gm...>]

2015-09-30 18:24 GMT+02:00 Albert <alb...@gm...>:
> Based on the message in bugzilla:
>
> I've just pushed a proposed solution to github (pull request 400).

Thanks a lot. Ingolf