doxygen-users — List for users of doxygen

[Doxygen-users] enum value of "NONE" is not understood by Doxygen.

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

In this example:

AClass.h

enum AnEnum {
 NONE=0, A_VALUE, B_VALUE
};


AClass.cpp

/*! \enum AnEnum
 * \brief Various useful values
*/

/*! \var A_VALUE
 * \brief THe value of A
*/

/*! \var B_VALUE
 * \brief THe value of B
*/

/*! \var NONE
 * \brief A value of zero
*/


Doxygen gives me the warning message:

Warning: no matching class member found for AnEnum::NONE

If I change the name of "NONE" to "NONE*X*", I don't have this warning. So
it would seem that
"NONE" is not understood properly by doxygen as an enum value. 

Does anyone know if I can get around this somehow (other than by renaming
"NONE"). This would seem to be a bug in Doxygen.




--
View this message in context: http://doxygen.10944.n7.nabble.com/enum-value-of-NONE-is-not-understood-by-Doxygen-tp6541.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] Preprocessor templates

[byron.hawkins <by...@ha...>]

I'm trying to generate docs for a simple vector in C, which uses preprocessor
statements to simulate a C++ template. It's not possible to use C++ because
the vector is used in an in-process virtualization layer that is written in
C, and also it is required to use the heap in very restricted ways. The
vector's init() function looks like:

    bool
    VECTOR_NAME(,NAME_KEY,_init)(VECTOR_TYPE *vec, uint initial_capacity,
bool synch
        _IF_ELEMENT_POINTER(, void (*free_data_func)(ELEMENT_TYPE))
        _IF_SORTED(, int (*comparator)(ELEMENT_TYPE, COMPARISON_TYPE)));

All the tokens in capitals are defined by the client module above the
`#include`, so for example a client source file might have:

    #define NAME_KEY account_vector
    #define ELEMENT_TYPE account_t*
    #define COMPARISON_TYPE unsigned int
    #define SORTED 1
    #include "tvectorx.h"

This would generate a function:

    bool
    account_vector_init(account_vector_t *vec, unsigned int
initial_capacity, bool synch,
        void (*free_data_func)(account_t*),
        int (*comparator)(account_t*, unsigned int));

Not surprisingly, doxygen is not able to parse all the preprocessor stuff.
It comes out like this in the html:

    bool tvector_init (VECTOR_NAME(, NAME_KEY, _t)*vec, uint
initial_capacity, 
        bool synch, void(*free_data_func)(void *), 
        int(*comparator)(void *, VECTOR_COMPARISON_TYPE))

(Some default substitutions have been made.) Is there a way to just override
the doxygen function declaration with a plain string, so that doxygen
displays the string instead of what it would normally parse out of the code?
Thanks for your help.




--
View this message in context: http://doxygen.10944.n7.nabble.com/Preprocessor-templates-tp6540.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] Doxygen for QtScript

[Anmol A. <an...@gm...>]

Hey :)

I was working on revamping Amarok's scripting interface, and an important
part of that happens to be the scripting interface documentation.

Amarok's functionality is exposed via qtscript objects, like
Amarok.Window.Statusbar for the statusbar [0]. Since the scripting
interface is targeted at script writers, I would like a separate doxygen
page, representing the qtscript object hierarchy, which differs from that
of the C++ code.

However, I cannot find a way to properly represent that using doxygen,
except for perhaps using a custom script to generate pseudo-headers for
doxification (sample script[1], output[2]). Could you please tell me if
there is a better way of going about it?

[0]
http://fisheye.amarok.kde.org/browse/Amarok/src/scriptengine/AmarokStatusbarScript.cpp?r=edf3724e618ea5da37e58df910782cf38d7a3353&r=dc07b000441a7669fb8ad1a37dd06019f4cc72f9
[1] https://gist.github.com/anonymous/6063843
[2] http://www.amarokscriptdox.appspot.com/

--
Regards,
Anmol Ahuja

Re: [Doxygen-users] Question on brief and detailed description

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

Tom,

Did you have a look at commands like @verbatim ?

Albert


On Sat, Mar 8, 2014 at 5:56 PM, Tom Geraedts <ger...@gm...> wrote:

> Dear mailinglist,
>
> I have been very busy trying to integrate doxygen into a software archive.
> It will be a huge improvement!
>
> However, I'm running into an annoying problem which I cant seem to solve
> at the moment.
>
> I have the following file description, which is is not correctly
> recognized as a single text, but broken up into text descriptions and
> something that looks like tagged code descriptions. I'm not sure now what
> to do to tell doxygen that the whole text should be seen as text only.
>
> File description example:
>
> /// \file example.cpp
> ///      This module processes example signals (samples) inorder to
> ///      reduce example artefacts originating from example motion.
> ///      This is realised using the example example example example
> ///      (example) method, which relies on two principles:
> ///
> ///      -   Example text example text
> ///          Example text example text
> ///          Example text example text
> ///
> ///      The following example illustrates this for a example example
> resolution:
> ///
> ///                   **                                    **
> ///  ^ example **  *                                 **  *
> ///  | example *     *                               *
> ///  |           **       *                            **
> ///  |          *          *                          *      ----> time
> ///            *            **                       *
> ///        ****               *****              ****
> ///    ****                        **************
> ///
> ///                        |<------------------------>|
> ///                                example
> ///
> ///                  |__________________|__________________|
> ///                -128                 0                +127  ---->
> ///                                                           optimum
> ///                                                           ky-value
> ///
> ///      The term 'example' refers to the following: each time when a
> ///      exampleis done, there is only one example-value which perfectly
> ///      matches the example example at that time.
>
> In this specific example, the lines with stars in it are not displayed as
> normal text.
>
> I'm quite sure that somehow doxygen see 'tags' that indicate code
> descriptions or something similar.
>
> Best regards,
>
> Tom
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

[Doxygen-users] Question on brief and detailed description

[Tom G. <ger...@gm...>]

Dear mailinglist,

I have been very busy trying to integrate doxygen into a software archive.
It will be a huge improvement!

However, I'm running into an annoying problem which I cant seem to solve at
the moment.

I have the following file description, which is is not correctly recognized
as a single text, but broken up into text descriptions and something that
looks like tagged code descriptions. I'm not sure now what to do to tell
doxygen that the whole text should be seen as text only.

File description example:

/// \file example.cpp
///      This module processes example signals (samples) inorder to
///      reduce example artefacts originating from example motion.
///      This is realised using the example example example example
///      (example) method, which relies on two principles:
///
///      -   Example text example text
///          Example text example text
///          Example text example text
///
///      The following example illustrates this for a example example
resolution:
///
///                   **                                    **
///  ^ example **  *                                 **  *
///  | example *     *                               *
///  |           **       *                            **
///  |          *          *                          *      ----> time
///            *            **                       *
///        ****               *****              ****
///    ****                        **************
///
///                        |<------------------------>|
///                                example
///
///                  |__________________|__________________|
///                -128                 0                +127  ---->
///                                                           optimum
///                                                           ky-value
///
///      The term 'example' refers to the following: each time when a
///      exampleis done, there is only one example-value which perfectly
///      matches the example example at that time.

In this specific example, the lines with stars in it are not displayed as
normal text.

I'm quite sure that somehow doxygen see 'tags' that indicate code
descriptions or something similar.

Best regards,

Tom

[Doxygen-users] Suppress "Referenced by" list for specific objects

[Peter B. <pd...@ma...>]

Hello Folks,

We have some functions and macros that are so widely used the "Referenced by" list is pages long. (Think logging, assertions, …)  

How can I selectively suppress this list for those objects, both macros and functions.

Basically I want just those objects to behave as if REFERENCED_BY_RELATION=NO, while its YES in the config file.

For the macros I tried adding them to PREDEFINED in our doxygen config file but that didn't help.

(I searched the list archives and StackOverflow but didn't find anything relevant.)

Oh, this is a C++ project, if that's relevant (but the problem seems general).

Thanks,
Peter
____________
Peter Barnes
pd...@ma...

Re: [Doxygen-users] `make` fails (probably) because of libiconv

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

Hi Guiseppe,

I assume you ran configure again.
Your libiconv is not on a standard place (when I remember well) so you
probably also have to add the -L to that path.

Albert



On Tue, Mar 4, 2014 at 9:03 PM, Giuseppe Crino' <gi...@gm...> wrote:

> On 1 March 2014 19:02, Dimitri van Heesch <do...@gm...> wrote:
>
>> On most Linux systems libiconv is part of libc (see also
>> http://en.wikipedia.org/wiki/Iconv),
>> on other systems it has to be linked explicitly.
>>
>> Your system seems to require explicit linking despite being a Linux
>> system.
>> Assuming you use the linux-g++ configuration, you could try to modify
>> TMAKE_LIBS in
>> tmake/lib/linux-g++/tmake.conf as follows:
>>
>> TMAKE_LIBS = -liconv
>>
>
> No, it does not work. But it is curious that though I've modified
> tmake.conf as you advised me output remains the same when error occurs in
> making, i.e.
>
> make[2]: Entering directory `/home/giuscri/doxygen-1.8.6/src'
> g++  -o ../bin/doxygen ../objects/main.o  -L../lib -ldoxygen -ldoxycfg
> -lqtools -lmd5 -lpthread
> ../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv_open':
> portable_c.c:(.text+0x1): undefined reference to `libiconv_open'
> ../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv':
> portable_c.c:(.text+0x11): undefined reference to `libiconv'
> ../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv_close':
> portable_c.c:(.text+0x21): undefined reference to `libiconv_close'
>
> while I would have expected
>
> g++  -o ../bin/doxygen ../objects/main.o  -L../lib -ldoxygen -ldoxycfg
> -lqtools \
>   -lmd5 **-liconv** -lpthread
>
> Am I wrong?
>
> --
> **Guerilla Open Access Movement**
> >
> http://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

[Doxygen-users] Fwd: `make` fails (probably) because of libiconv

[Giuseppe Crino' <gi...@gm...>]

On 1 March 2014 18:53, Albert <alb...@gm...> wrote:

> Hi Guseppe,
>
> I see a similar question on stack exchange (
> http://stackoverflow.com/questions/21997908/doxygen-build-failing-with-undefined-reference-to-libiconv-close-libiconv
> ).
>
> I tried it on a RHEL system and there the iconv is coming from glibc (by
> head version 2.2.5), on cygwin the -liconv is explicitly added to the link
> line (in the configuration step in src/doxygen.pro.in).
>
> Albert
>

You're suggesting me to modify src/doxygen.pro.in, right? I tried, with no
results ... I copied doxygen.pro.in into doxygen.pro.in.old, edited
doxygen.pro.in and here's to output of diff

$ diff src/doxygen.pro.in src/doxygen.pro.in.old
21c21
< unix:LIBS                  += -L../lib -ldoxygen -ldoxycfg -lqtools -lmd5
-liconv -lpthread %%SQLITE3_LIBS%% %%LIBCLANG_LIBS%%
---
> unix:LIBS                  += -L../lib -ldoxygen -ldoxycfg -lqtools -lmd5
-lpthread %%SQLITE3_LIBS%% %%LIBCLANG_LIBS%%

It is curious, as happens also following Dimitri's suggestion, that the
output of make does not change. Indeed

make[2]: Entering directory `/home/giuscri/doxygen-1.8.6/src'
g++  -o ../bin/doxygen ../objects/main.o  -L../lib -ldoxygen -ldoxycfg
-lqtools -lmd5 -lpthread
../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv_open':
portable_c.c:(.text+0x1): undefined reference to `libiconv_open'
../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv':
portable_c.c:(.text+0x11): undefined reference to `libiconv'
../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv_close':
portable_c.c:(.text+0x21): undefined reference to `libiconv_close'
collect2: error: ld returned 1 exit status
...


-- 
**Guerilla Open Access Movement**
>
http://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt

[Doxygen-users] `make` fails (probably) because of libiconv

[Giuseppe Crino' <gi...@gm...>]

On 1 March 2014 19:02, Dimitri van Heesch <do...@gm...> wrote:

> On most Linux systems libiconv is part of libc (see also
> http://en.wikipedia.org/wiki/Iconv),
> on other systems it has to be linked explicitly.
>
> Your system seems to require explicit linking despite being a Linux system.
> Assuming you use the linux-g++ configuration, you could try to modify
> TMAKE_LIBS in
> tmake/lib/linux-g++/tmake.conf as follows:
>
> TMAKE_LIBS = -liconv
>

No, it does not work. But it is curious that though I've modified
tmake.conf as you advised me output remains the same when error occurs in
making, i.e.

make[2]: Entering directory `/home/giuscri/doxygen-1.8.6/src'
g++  -o ../bin/doxygen ../objects/main.o  -L../lib -ldoxygen -ldoxycfg
-lqtools -lmd5 -lpthread
../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv_open':
portable_c.c:(.text+0x1): undefined reference to `libiconv_open'
../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv':
portable_c.c:(.text+0x11): undefined reference to `libiconv'
../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv_close':
portable_c.c:(.text+0x21): undefined reference to `libiconv_close'

while I would have expected

g++  -o ../bin/doxygen ../objects/main.o  -L../lib -ldoxygen -ldoxycfg
-lqtools \
  -lmd5 **-liconv** -lpthread

Am I wrong?

-- 
**Guerilla Open Access Movement**
>
http://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt

Re: [Doxygen-users] Installing doxygen 1.8.6 with Xapian search engine

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

Hi Nasir,

I see a similar question on stack exchange (
http://stackoverflow.com/questions/21997908/doxygen
-build-failing-with-undefined-reference-to-libiconv-close-libiconv).
and also in this list.

I dont see a reference to the (non standard) library path
(/work/cara/common/testTools/
libiconv/1.14/lib) in your link line
I tried it on a RHEL system and there the iconv is coming from glibc (by
head version 2.2.5), on cygwin the -liconv is explicitly added to the link
line (in the configuration step in src/doxygen.pro.in).

Albert




On Tue, Mar 4, 2014 at 8:39 AM, Nasir Kadiri <nas...@gm...> wrote:

> Hi,
>
> I already installed latest release of doxygen (1.8.6) and I want to use
> the new feature which is using external search engine in generated HTML
> documentation. My project is huge and default search engine is very slow.
> In doxygen we have integrated search indexer and search engine which is
> based on source search engine library Xapian.
>
> I am trying to install Xapian 1.2.17 and needed libraries i.e.
> Xapain-omega. I can see that installation of those are ok. I configure
> (./configure) installation of doxygen 1.8.6 and after that try to run make,
> I get following error:
>
> gmake[2]: Entering directory
> `/prj/cara/common/Nasir_testing/doxygen-1.8.6/addon/doxyapp'
> g++ -g -o ../../bin/doxyapp ../../objects/doxyapp.o  -L../../lib -ldoxygen
> -lqtools -lmd5 -ldoxycfg -lpthread -liconv
> -L/work/cara/common/testTools/xapian-core/1.2.17/lib
> /usr/bin/ld: cannot find -liconv
> collect2: ld returned 1 exit status
> gmake[2]: *** [../../bin/doxyapp] Error 1
> gmake[2]: Leaving directory
> `/prj/cara/common/Nasir_testing/doxygen-1.8.6/addon/doxyapp'
> gmake[1]: *** [all] Error 2
> gmake[1]: Leaving directory
> `/prj/cara/common/Nasir_testing/doxygen-1.8.6/addon/doxyapp'
> make: *** [all] Error 2
> I really Don't know why it tries to search for iconv binaries under
> xapian-core but not from the right location
> (/work/cara/common/testTools/libiconv/1.14/lib/libiconv.so).
>
> Can anybody help on that?
>
> Thanks in advance,
> Nasir
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

Re: [Doxygen-users] Fwd: `make` fails (probably) because of libiconv

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

Hi Guseppe,

I see a similar question on stack exchange (
http://stackoverflow.com/questions/21997908/doxygen
-build-failing-with-undefined-reference-to-libiconv-close-libiconv).

I tried it on a RHEL system and there the iconv is coming from glibc (by
head version 2.2.5), on cygwin the -liconv is explicitly added to the link
line (in the configuration step in src/doxygen.pro.in).

Albert

(Forgot to include list in response)


On Sat, Mar 1, 2014 at 6:03 PM, Giuseppe Crino' <gi...@gm...> wrote:

> Hi,
>
> I can't correctly build doxygen on my system. To be more precise, `make`
> fails since
>
> ../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv_open':
> portable_c.c:(.text+0x1): undefined reference to `libiconv_open'
> ../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv':
> portable_c.c:(.text+0x11): undefined reference to `libiconv'
> ../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv_close':
> portable_c.c:(.text+0x21): undefined reference to `libiconv_close'
> collect2: error: ld returned 1 exit status
> make[2]: *** [../bin/doxygen] Error 1
> make[2]: Leaving directory `/home/giuscri/doxygen-1.8.6/src'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/giuscri/doxygen-1.8.6/src'
> make: *** [all] Error 2
>
> To me, something wrong with libiconv is there. Indeed, for the libiconv
> building to succeed I needed to comment line 689 of
> `path/to/libiconv/srclib/stdio.in.h` such that
>
>  682 #if @GNULIB_GETS@
>  683 # if @REPLACE_STDIO_READ_FUNCS@ && @GNULIB_STDIO_H_NONBLOCKING@
>  684 #  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
>  685 #   undef gets
>  686 #   define gets rpl_gets
>  687 #  endif
>  688 _GL_FUNCDECL_RPL (gets, char *, (char *s) _GL_ARG_NONNULL ((1)));
>  689 _GL_CXXALIAS_RPL (gets, char *, (char *s));
>  690 # else
>  691 _GL_CXXALIAS_SYS (gets, char *, (char *s));
>  692 #  undef gets
>  693 # endif
>  694 _GL_CXXALIASWARN (gets);
>  695 /* It is very rare that the developer ever has full control of stdin,
>  696    so any use of gets warrants an unconditional warning.  Assume it is
>  697    always declared, since it is required by C89.  */
>  698 //_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets
> instead"     );
>  699 #endif
>
> I'm u
> sing doxygen-1.8.6. Output for `uname -a`
> is
>
>     Linux banzi 3.11.0-15-generic #25-Ubuntu SMP Thu Jan 30 17:25:07 UTC
> 2014 \
>     i686 i686 i686 GNU/Linux
>
> Follows complete output of building process (from `./configure`).
>
> http://pastebin.com/b4mQG2wi
>
> Any help?
>
> Thank you,
>
> Giuseppe
>
>
>
> --
> **Guerilla Open Access Movement**
> >
> http://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt
>
>
>
> --
> **Guerilla Open Access Movement**
> >
> http://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

[Doxygen-users] Installing doxygen 1.8.6 with Xapian search engine

[Nasir K. <nas...@gm...>]

Hi,

I already installed latest release of doxygen (1.8.6) and I want to use the
new feature which is using external search engine in generated HTML
documentation. My project is huge and default search engine is very slow.
In doxygen we have integrated search indexer and search engine which is
based on source search engine library Xapian.

I am trying to install Xapian 1.2.17 and needed libraries i.e.
Xapain-omega. I can see that installation of those are ok. I configure
(./configure) installation of doxygen 1.8.6 and after that try to run make,
I get following error:

gmake[2]: Entering directory
`/prj/cara/common/Nasir_testing/doxygen-1.8.6/addon/doxyapp'
g++ -g -o ../../bin/doxyapp ../../objects/doxyapp.o  -L../../lib -ldoxygen
-lqtools -lmd5 -ldoxycfg -lpthread -liconv
-L/work/cara/common/testTools/xapian-core/1.2.17/lib
/usr/bin/ld: cannot find -liconv
collect2: ld returned 1 exit status
gmake[2]: *** [../../bin/doxyapp] Error 1
gmake[2]: Leaving directory
`/prj/cara/common/Nasir_testing/doxygen-1.8.6/addon/doxyapp'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory
`/prj/cara/common/Nasir_testing/doxygen-1.8.6/addon/doxyapp'
make: *** [all] Error 2
I really Don't know why it tries to search for iconv binaries under
xapian-core but not from the right location
(/work/cara/common/testTools/libiconv/1.14/lib/libiconv.so).

Can anybody help on that?

Thanks in advance,
Nasir

[Doxygen-users] How to documentate a document.ready javascript ?

[Antonomase <en...@bt...>]

Hi,
I want to documentate a js file which contains something like
$(document).ready(function () {	$("#jqxTopMenu").jqxMenu({ width: '100%',
theme: theme });	$("#jqxTopMenu").css('visibility', 'visible');	...});
But I got a documentation with all the source code.How to documentate that ?
Another question : can I documentate an HTML file which contains javascript
?
Thanks



--
View this message in context: http://doxygen.10944.n7.nabble.com/How-to-documentate-a-document-ready-javascript-tp6528.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] How to documentate template files

[Antonomase <en...@bt...>]

Hi,
My developments are made with php and Smarty, a template system which
extensions files are .tpl. I want to have documentation on these template in
the same way that documentation about php or js.
I try to documentate the .tpl files by just adding this at the top of my
template file
{*/** * \file head.inc.tpl * \brief My comment */*}
but the file do not appear in the documentation.How can I these files
?Thanks



--
View this message in context: http://doxygen.10944.n7.nabble.com/How-to-documentate-template-files-tp6527.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] How to documentate a jQuery Extension ?

[Antonomase <en...@bt...>]

Hi,I want to documentate the javascript which extends JQuery
$.extend({  getUrlVar: function(name){    return $.getUrlVars()[name];  }});
I try \fn getUrlVar, but Doxygen do not find the function.I try extend but
Doxygen show all the source code in the doc.What can i use ?Best regards



--
View this message in context: http://doxygen.10944.n7.nabble.com/How-to-documentate-a-jQuery-Extension-tp6524.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] How to documentate a jQuery Extension ?

[Antonomase <en...@bt...>]

Hi, I want to documentate the javascript which extends JQuery
$.extend({  getUrlVar: function(name){    return $.getUrlVars()[name];  }});
I try \fn getUrlVar, but Doxygen do not find the function.I try extend but
Doxygen show all the source code in the doc.What can i use ? Best regards 



--
View this message in context: http://doxygen.10944.n7.nabble.com/How-to-documentate-a-jQuery-Extension-tp6525.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] Fwd: `make` fails (probably) because of libiconv

[Giuseppe Crino' <gi...@gm...>]

Hi,

I can't correctly build doxygen on my system. To be more precise, `make`
fails since

../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv_open':
portable_c.c:(.text+0x1): undefined reference to `libiconv_open'
../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv':
portable_c.c:(.text+0x11): undefined reference to `libiconv'
../lib/libdoxycfg.a(portable_c.o): In function `portable_iconv_close':
portable_c.c:(.text+0x21): undefined reference to `libiconv_close'
collect2: error: ld returned 1 exit status
make[2]: *** [../bin/doxygen] Error 1
make[2]: Leaving directory `/home/giuscri/doxygen-1.8.6/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/giuscri/doxygen-1.8.6/src'
make: *** [all] Error 2

To me, something wrong with libiconv is there. Indeed, for the libiconv
building to succeed I needed to comment line 689 of
`path/to/libiconv/srclib/stdio.in.h` such that

 682 #if @GNULIB_GETS@
 683 # if @REPLACE_STDIO_READ_FUNCS@ && @GNULIB_STDIO_H_NONBLOCKING@
 684 #  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
 685 #   undef gets
 686 #   define gets rpl_gets
 687 #  endif
 688 _GL_FUNCDECL_RPL (gets, char *, (char *s) _GL_ARG_NONNULL ((1)));
 689 _GL_CXXALIAS_RPL (gets, char *, (char *s));
 690 # else
 691 _GL_CXXALIAS_SYS (gets, char *, (char *s));
 692 #  undef gets
 693 # endif
 694 _GL_CXXALIASWARN (gets);
 695 /* It is very rare that the developer ever has full control of stdin,
 696    so any use of gets warrants an unconditional warning.  Assume it is
 697    always declared, since it is required by C89.  */
 698 //_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead"
    );
 699 #endif

I'm u
sing doxygen-1.8.6. Output for `uname -a`
is

    Linux banzi 3.11.0-15-generic #25-Ubuntu SMP Thu Jan 30 17:25:07 UTC
2014 \
    i686 i686 i686 GNU/Linux

Follows complete output of building process (from `./configure`).

http://pastebin.com/b4mQG2wi

Any help?

Thank you,

Giuseppe



-- 
**Guerilla Open Access Movement**
>
http://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt



-- 
**Guerilla Open Access Movement**
>
http://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt

Re: [Doxygen-users] Doxygen 1.8.6 unusable to build our doc due to tag_files generated

[Sebastien L. (GeometryFactory) <slo...@gm...>]

On 02/28/2014 10:33 PM, Dimitri van Heesch wrote:
> Hi Sebastien,
>
Hi Dimitri,

> On 28 Feb 2014, at 10:59 , Sebastien Loriot <slo...@gm...> wrote:
>
>> Hello,
>>
>> Our library documentation is decomposed into packages and each package
>> documentation has its own doxygen compilation unit. The links between
>> the packages are handled thanks to the tag-files.
>> The build is OK when using doxygen 1.8.4.
>>
>> When we tried to switch to 1.8.6 we noticed that the second build
>> (the first build generates the tag-files) allocates huge amounts of
>> memory making the computer swapping and unusable.
>> If I use doxygen 1.8.4 for the second build (i.e. using tag-files from
>> doxygen 1.8.6), the behavior is the same.
>>
>> I tried to make a small reproducible test case without success.
>> One of our developer suspects this commit 31198c21.
>>
>> Is it a known issue?
>> If this can help, I can find out what in the diff of the tag-files
>> cause the issue. What I quickly notice in the diff are:
>> -change in anchor hash
>> -extra <type>@</type> in enums
>> -more members and class are exported
>
>
> It is not a known issue, and I would like to understand better what is causing this.
> Some things to get clear first:
> - are you using the latest from GitHub or the standard 1.8.6 release?
> - is doxygen eating all memory and hanging indefinitely/crashing when out of memory, or
>    just using more memory but finally finishing just fine?
> - if you generate the tag files with version 1.8.4, does the second run then work with 1.8.6?
>
I just tried with the latest git version and it seems you already have 
fixed the issue. I should have tried it first, sorry for the noise.


Best regards,

Sebastien.

> Regards,
>    Dimitri
>

Re: [Doxygen-users] Doxygen 1.8.6 unusable to build our doc due to tag_files generated

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

Hi Sebastien,

On 28 Feb 2014, at 10:59 , Sebastien Loriot <slo...@gm...> wrote:

> Hello,
> 
> Our library documentation is decomposed into packages and each package
> documentation has its own doxygen compilation unit. The links between
> the packages are handled thanks to the tag-files.
> The build is OK when using doxygen 1.8.4.
> 
> When we tried to switch to 1.8.6 we noticed that the second build
> (the first build generates the tag-files) allocates huge amounts of
> memory making the computer swapping and unusable.
> If I use doxygen 1.8.4 for the second build (i.e. using tag-files from 
> doxygen 1.8.6), the behavior is the same.
> 
> I tried to make a small reproducible test case without success.
> One of our developer suspects this commit 31198c21.
> 
> Is it a known issue?
> If this can help, I can find out what in the diff of the tag-files
> cause the issue. What I quickly notice in the diff are:
> -change in anchor hash
> -extra <type>@</type> in enums
> -more members and class are exported


It is not a known issue, and I would like to understand better what is causing this.
Some things to get clear first:
- are you using the latest from GitHub or the standard 1.8.6 release?
- is doxygen eating all memory and hanging indefinitely/crashing when out of memory, or 
  just using more memory but finally finishing just fine?
- if you generate the tag files with version 1.8.4, does the second run then work with 1.8.6?

Regards,
  Dimitri

[Doxygen-users] Doxygen 1.8.6 unusable to build our doc due to tag_files generated

[Sebastien L. <slo...@gm...>]

Hello,

Our library documentation is decomposed into packages and each package
documentation has its own doxygen compilation unit. The links between
the packages are handled thanks to the tag-files.
The build is OK when using doxygen 1.8.4.

When we tried to switch to 1.8.6 we noticed that the second build
(the first build generates the tag-files) allocates huge amounts of
memory making the computer swapping and unusable.
If I use doxygen 1.8.4 for the second build (i.e. using tag-files from 
doxygen 1.8.6), the behavior is the same.

I tried to make a small reproducible test case without success.
One of our developer suspects this commit 31198c21.

Is it a known issue?
If this can help, I can find out what in the diff of the tag-files
cause the issue. What I quickly notice in the diff are:
-change in anchor hash
-extra <type>@</type> in enums
-more members and class are exported

Thanks,

Sebastien.

Re: [Doxygen-users] Documenting entities in empty namspace

[Greg A. <Gre...@do...>]

Is this the configuration option you're looking for?
<http://www.stack.nl/~dimitri/doxygen/manual/config.html#cfg_extract_anon_nspaces>


> -----Original Message-----
> From: Brad Bell [mailto:bra...@se...]
> Sent: 27 February 2014 14:33
> To: dox...@li...
> Subject: [Doxygen-users] Documenting entities in empty namspace
>
> How does one include doxygen documentation for entities in the empty
> namespace ?
>
> For example, if you execute the bash script below, the documentation for
>      function_in_empty_namespace
> is missing:
> ----------------
> #! /bin/bash -e
> cat << EOF
> This script creates a C++ source file called
>       build/empty_namespace.cpp
> and corresponding html documentation in
>       build/html/files.html
> If you view the source file and the html documentation, you will see that
> the html documentation for the function in the empty namespace is missing.
> EOF
> cat << EOF > build/empty_namespace.cpp
> /// @file empty_namespace.cpp
> /// @brief Doxygen example showing that empty namespace functions are
> missing
> namespace {
>       /// A documented function in the empty namespace
>       int function_in_empty_namespace(void)
>       {    return 1; }
> }
>
> /// A documented function not in empty namespace
> void function_outside_empty_namespace(void)
> {    std::cout << function_in_empty_namespace(void) << std::endl;
> }
> EOF
> echo
> if [ ! -e build ]
> then
>       mkdir build
> fi
> echo 'cd build'
> cd build
> echo "doxygen -g doxyfile  > doxyfile.log"
> doxygen -g doxyfile  > doxyfile.log
> #
> echo "sed -e 's|\(^INPUT *\)=.*|\1= empty_namespace.cpp|' -i doxyfile"
> sed -e 's|\(^INPUT *\)=.*|\1= empty_namespace.cpp|' -i doxyfile
> #
> echo "sed -e 's|\(^SOURCE_BROWSER *\)=.*|\1= YES|' -i doxyfile"
> sed -e 's|\(^SOURCE_BROWSER *\)=.*|\1= YES|' -i doxyfile
> sed -e 's|\(^STRIP_CODE_COMMENTS *\)=.*|\1= NO|' -i doxyfile
> #
> echo "doxygen doxyfile  > doxygen.log"
> doxygen doxyfile  > doxygen.log
>
>
> ----------------------------------------------------------------------------
> --
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
This Email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any reading, redistribution, disclosure or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender immediately and delete the material from your computer. E-mail may be susceptible to data corruption, interception, viruses and unauthorised amendment and Domino UK Limited<http://www.domino-printing.com/Channels/UK/eng/Home.aspx> does not accept liability for any such corruption, interception, viruses or amendment or their consequences.


Domino UK Limited<http://www.domino-printing.com/Channels/UK/eng/Home.aspx> Registered in England. Registered Number:1750201. Registered Office Address: Trafalgar Way, Bar Hill, Cambridge, CB23 8TU.

[Doxygen-users] Documenting entities in empty namspace

[Brad B. <bra...@se...>]

How does one include doxygen documentation for entities in the empty  
namespace ?

For example, if you execute the bash script below, the documentation for
     function_in_empty_namespace
is missing:
----------------
#! /bin/bash -e
cat << EOF
This script creates a C++ source file called
      build/empty_namespace.cpp
and corresponding html documentation in
      build/html/files.html
If you view the source file and the html documentation, you will see that
the html documentation for the function in the empty namespace is missing.
EOF
cat << EOF > build/empty_namespace.cpp
/// @file empty_namespace.cpp
/// @brief Doxygen example showing that empty namespace functions are 
missing
namespace {
      /// A documented function in the empty namespace
      int function_in_empty_namespace(void)
      {    return 1; }
}

/// A documented function not in empty namespace
void function_outside_empty_namespace(void)
{    std::cout << function_in_empty_namespace(void) << std::endl;
}
EOF
echo
if [ ! -e build ]
then
      mkdir build
fi
echo 'cd build'
cd build
echo "doxygen -g doxyfile  > doxyfile.log"
doxygen -g doxyfile  > doxyfile.log
#
echo "sed -e 's|\(^INPUT *\)=.*|\1= empty_namespace.cpp|' -i doxyfile"
sed -e 's|\(^INPUT *\)=.*|\1= empty_namespace.cpp|' -i doxyfile
#
echo "sed -e 's|\(^SOURCE_BROWSER *\)=.*|\1= YES|' -i doxyfile"
sed -e 's|\(^SOURCE_BROWSER *\)=.*|\1= YES|' -i doxyfile
sed -e 's|\(^STRIP_CODE_COMMENTS *\)=.*|\1= NO|' -i doxyfile
#
echo "doxygen doxyfile  > doxygen.log"
doxygen doxyfile  > doxygen.log

Re: [Doxygen-users] Namespace page not generated

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

Posted on bugzilla
Bug 725201




--
View this message in context: http://doxygen.10944.n7.nabble.com/Namespace-page-not-generated-tp6497p6514.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] Best way to 'relocate' links to html

[Edward M. <Edw...@ce...>]

On 17 Feb 2014, at 21:17, Dimitri van Heesch <do...@gm...<mailto:do...@gm...>> wrote:

Hi Edward,

On 17 Feb 2014, at 16:32 , Edward Moyse <edw...@ce...<mailto:edw...@ce...>> wrote:

Hi all,

I'm just trying to understand why our doxygen builds take such an insane amount of time. I think we're not currently building tags first then making the html after, as recommended here:
http://stackoverflow.com/questions/8247189/doxygen-is-slow/8247993#8247993
and so I'm investigating changing this...

But also we seem to have an incredibly slow part of the process where the html is parsed to turn links like:
file:///my/local/path/doc/xAODMuon/html/classSG_1_1AuxElement.html

into
html://a/web/location/doc/xAODMuon/html/classSG_1_1AuxElement.html

(The reason for this is we build the documentation on a local machine, then once it's done it's copied to a web visible location)

Presumably there is a better way to do this? I'd have thought it should be possible to specify that the html will eventually live elsewhere, but I had a look at the documentation and couldn't see it?

Doxygen normally doesn't create any absolute URLs (with file:// or http:// in them), so the URL renaming process is not part of doxygen and shouldn't be needed at all. Just copy the HTML files to the web location in the end.

Hi Dimitri,

Thanks for the reply, and sorry for the delay in getting back to you - I've been trying to investigate a bit more before asking again.

What we have is a structure like the following:

ProjectA
PackageA
build
headers
src
PackageB
build
headers
src
ProjectB
PackageC
build
headers
src
PackageD
build
headers
src

What we try to end up with is:
Output/doc/
PackageA
html
PackageA.tag
PackageB
html
PackageB.tag
PackageC
html
PackageC.tag
PackageD
html
PackageD.tag

I'm trying to work out how best to achieve this...

What I'm trying right now involves two steps (as you suggested):
1) loop through each package (in the original location), build the tagfile of the package and output it to Output/PackageX.tag
2) loop through each package again (again in the original location), and generate the html in Output/PackageX/html

For both step1 and step2 the generated Doxyfiles (one per package) have:
OUTPUT_DIRECTORY = /Output/doc/PackageX
INLINE_SOURCES         = YES

For step 1, the Doxyfile has :
GENERATE_HTML = NO
TAGFILES =
GENERATE_TAGFILE = /Output/doc/PackageX.tag

For step 2, the Doxyfile has:
GENERATE_HTML = YES
TAGFILES = /Output/doc/PackageA.tag=/Output/doc/PackageA/html
i.e. paths are absolute (since the relative path isn't reliable - the build location can change).

There are quite a few problems unfortunately.

1) INLINE_SOURCES seems to be ignored... (which is just ver
2) Many links don't work.

For example, PackageA has MyObjectA which uses MyObjectB from PackageB, and both exist in the namespace Foo.

In the generated documentation for MyObjectA, there is a link to MyObjectB, but in fact it points to

When I look into PackageB.tag, I see the following:
  <compound kind="file">
    <name> MyObjectB </name>
    <path>/ProjectA/PackageA/headers/</path>
    <filename> MyObjectB_8h</filename>
    <includes id="MyObjectB_8h" name="MyObjectB.h" local="yes" imported="no">versions/MyObjectB.h</includes>
    <namespace>Foo</namespace>
    <member kind="typedef">
      <type> MyObjectB_v1</type>
      <name> MyObjectB </name>
      <anchorfile>namespaceFoo.html</anchorfile>
      <anchor>a795ac8d2e30fdc75f7c9266766629005</anchor>
      <arglist></arglist>
    </member>
  </compound>

i.e. the anchorfile is somehow being misunderstood to be the namespace file. And the <path> tag points to the complete build directory (I'm not sure if this is a problem or not?). The problem here might be related to the fact that we make quite a lot of use of typedefs in these particular packages... In fact, I just tried changing some of the documentation to refer to ObjectB_v1 rather than ObjectB, and it worked correctly. But this is a bit of a pain, since we want to hide the version from users, and we don't want to have to update all the documentation once the version changes.

A related question - is there any way to tell Doxygen that, never mind how many packages you find namespace Foo in, THIS is the definitive documentation and to only use this? We have Foo spread across hundreds of packages, unfortunately.

Thanks in advance for any debugging tips you could give (I hope the above is comprehensible - I'm having to obfuscate our code, which makes this a lot more painful to explain!)

Cheers,

Ed

[Doxygen-users] Using Doxygen 1.8.6 for generating documentation of projects compiled with clang

[Khirod K. N. <khi...@gm...>]

Is it possible to use doxygen for generating documentation of projects that
use a clang compiler. I have to generate documentation for a project that
uses Clang. I am not sure if doxygen could be used for this??

If yes, please guide me how to do this??