doxygen-users — List for users of doxygen

Re: [Doxygen-users] 1.8.5 throws many "Internal Inconsistency" errors when parsing .idl files

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

A number of error messages lacked the '\n' character, I've pushed a
solution to git (pull request 69).
(Note: I've not been able to test it on actual idl code, so there might be
more places but this would require an example that signals the problems).

Albert


On Fri, Dec 13, 2013 at 9:37 AM, _ph_ <hau...@ya...> wrote:

> 1.8.5 (and possibly earlier versions), when parsing a .idl file, throws
> tons
> of
>
>     error: Internal inconsistency: namespace in IDL not module or cg
>
> without a (windows-proper) line break at the end, so the output becomes a
> wall of text, wiht some useful messages hidden in it.
>
> So output basically looks like pages of this:
>
> error: Internal inconsistency: namespace in IDL not module or cgerror:
> Internal inconsistency: namespace in IDL not module or cgerror: Internal
> inconsistency: namespace in IDL not module or cgerror: Internal
> inconsistency: namespace in IDL not module or cgerror: Internal
> inconsistency: namespace in IDL not module or
> cgD:/SourcesVC9/Master/Sources/Common/_Interface/kadaitf.idl(774): warning:
> unable to resolve reference to `CKLDBSession::initNoSyncWrite' for \ref
> command
>
> Is this a known problem? I can provide settings + code for reproducign the
> problem, if needed.
>
>
>
>
> --
> View this message in context:
> http://doxygen.10944.n7.nabble.com/1-8-5-throws-many-Internal-Inconsistency-errors-when-parsing-idl-files-tp6401.html
> Sent from the Doxygen - Users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

[Doxygen-users] 1.8.5 throws many "Internal Inconsistency" errors when parsing .idl files

[_ph_ <hau...@ya...>]

1.8.5 (and possibly earlier versions), when parsing a .idl file, throws tons
of 

    error: Internal inconsistency: namespace in IDL not module or cg

without a (windows-proper) line break at the end, so the output becomes a
wall of text, wiht some useful messages hidden in it. 

So output basically looks like pages of this:

error: Internal inconsistency: namespace in IDL not module or cgerror:
Internal inconsistency: namespace in IDL not module or cgerror: Internal
inconsistency: namespace in IDL not module or cgerror: Internal
inconsistency: namespace in IDL not module or cgerror: Internal
inconsistency: namespace in IDL not module or
cgD:/SourcesVC9/Master/Sources/Common/_Interface/kadaitf.idl(774): warning:
unable to resolve reference to `CKLDBSession::initNoSyncWrite' for \ref
command

Is this a known problem? I can provide settings + code for reproducign the
problem, if needed. 




--
View this message in context: http://doxygen.10944.n7.nabble.com/1-8-5-throws-many-Internal-Inconsistency-errors-when-parsing-idl-files-tp6401.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] USE_MDFILE_AS_MAINPAGE doesn't work

[Hong Xu <ho...@to...>]

Hi all,

I tried to use USE_MDFILE_AS_MAINPAGE to generate a main page by doxygen 
1.8.5, but it doesn't work as expected. The page is generated, however, 
it's not the main page.

I also have specified the full path to the markdown file in the INPUT, 
MARKDOWN_SUPPORT is set to YES.

The source tree is here: 
https://github.com/xuhdev/multidiminte/blob/master/doc/Doxyfile.in

Could anyone help me please?

Thanks!
Hong

Re: [Doxygen-users] Alias defgroup?

[Ron W. <ron...@gm...>]

On Wed, Dec 4, 2013 at 10:55 AM, <
dox...@li...> wrote:

> Date: Wed, 27 Nov 2013 10:51:40 -0800
> From: mathog <ma...@ca...>
> On 27-Nov-2013 07:42, Ron Wilson wrote:
> >  Your enumeration could be expressed as an "enum" type, optionally using
> > one
> > or more "typedef"s to declare variables that use the enumeration.
>
> I was hoping for the one or two line tag to add to the doxygen
> documentation in the include file, rather than the thousand line rewrite
> of both the include files and all the code that uses them.
>
> Since Doxygen must have somewhere a data representation for
>
>   U_EMF_LOGBRUSH_lbStyle_Qualifiers <-  EMF LB_Style Enumeration
>
> it seemed likely that somewhere in its large set of commands Doxygen
> would have one that
> would result in
>
>   U_EMF_LOGBRUSH_lbStyle_Qualifiers <-  EMF LB_Style Enumeration
>   U_EMF_LOGBRUSH_lbStyle_Qualifiers <-  WMF BrushStyle Enumeration
>

Doxygen only sees #define symbols as individual symbols. Doxygen doesn't
infer any semmantic relationship between them even if you group them
together
using Doxtgen mark-up.

Using @defgroup, the closest aproximation I can come up with would be to
define (to Doxygen) a "master group", then each "use group" would @ref
(or @see) the master group and note the valid range and/or other exceptions.

(FYI, you would not need to rewrite your code. An enum is an integral type,
so

enum BrushStyle {
STYLE_SOLID,
};
int CurrentStyle = STYLE_SOLID;

is valid C. (Some compilers will emit warnings, but this is valid.))

[Doxygen-users] G722 ITU Testing

[Brent G. <bg...@so...>]

I am in charge of verifying the gst-ffmpeg G722 codecs meet the ITU requirements for a project I am working on. From the following link it states in the Detailed Description that the G.722 ADPCM audio codec passes the ITU tests.
http://ffmpeg.org/doxygen/trunk/g722_8c.html#_details

Not that I don't trust the web but I also like to learn how things were done. I have been using the test vectors from the ITU website and trying to run their Digital test sequences (Appendix II from the recommendation) to verify the codec. I've posted several emails to the ITU website asking for clarification on how these test are run because the comparison files they provide are the same size as the source files. Correct me if I am wrong but shouldn't the resulting file be smaller than the source file after passing through the encoder and larger for passing through the decoder?

Seeing how the ffmpeg.org website from above claims to have passed all the ITU websites I would like to know how these tests were done so I can prove this out for my management.

Brent Giles
Electrical Engineer
Sorenson Communications Inc
4192 Riverboat Road
Salt Lake City, Utah 84123
P: (801) 287-9442

CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at bg...@so...<mailto:bg...@so...> or by telephone at 801-287-9442, and destroy the original transmission and its attachments without reading them or saving them to disk.

Re: [Doxygen-users] Overloaded method in C# not recognized

[Brian B. <Bri...@Ve...>]

Thanks Stefan, this does indeed work. But you wind up with a link that looks
like this in your doc: AcUtils::AcDebug::Log(string, string, bool)

Is there a way to use the [description](@ref symbol) method to have the link
a bit less verbose?

Don't get me wrong, I'm thrilled about having a working link now. I can live
with it, so no big deal.

Thanks,
Brian




--
View this message in context: http://doxygen.10944.n7.nabble.com/Overloaded-method-in-C-not-recognized-tp6391p6395.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] Alias defgroup?

[mathog <ma...@ca...>]

On 27-Nov-2013 07:42, Ron Wilson wrote:
> On Wed, Nov 27, 2013 at 7:12 AM, <
> dox...@li...> wrote:
> 
>> Date: Tue, 26 Nov 2013 15:43:27 -0800
>> From: mathog <ma...@ca...>
>> 
>> Part 1:
>> 
>> This defgroup is defined (it is for a type of metafile) in file 
>> uemf.h:
>> 
>> /** \defgroup U_EMF_LOGBRUSH_lbStyle_Qualifiers EMF LB_Style 
>> Enumeration
...
>> 
>> /*  BrushStyle Enumeration                WMF manual 2.1.1.4
>>    Same as "EMF LB_Style Enumeration" in uemf.h
>> */
...
>> So how does one tell Doxygen that "BrushStyle Enumeration" as some 
>> sort
>> of alias
>> for the first enumeration?

> Your enumeration could be expressed as an "enum" type, optionally using 
> one
> or more "typedef"s to declare variables that use the enumeration.

I was hoping for the one or two line tag to add to the doxygen 
documentation in the include file, rather than the thousand line rewrite 
of both the include files and all the code that uses them.

Since Doxygen must have somewhere a data representation for

  U_EMF_LOGBRUSH_lbStyle_Qualifiers <-  EMF LB_Style Enumeration

it seemed likely that somewhere in its large set of commands Doxygen 
would have one that
would result in

  U_EMF_LOGBRUSH_lbStyle_Qualifiers <-  EMF LB_Style Enumeration
  U_EMF_LOGBRUSH_lbStyle_Qualifiers <-  WMF BrushStyle Enumeration

Regards,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Doxygen-users] Overloaded method in C# not recognized

[S X <sx...@fr...>]

Hi Brian,

Automatic link creation can do the job for you without the need to use a @ref. Just add the signature of the function you want to link to.

In your case Log(string,string,bool) should fix the problem.

Best,
Stefan

Brian Buttolph <Bri...@Ve...> schrieb:
>What should be in [Log](@ref ??) so Doxygen creates a link to the
>overloaded
>method (second one below)? A simple Log (without @ref) goes to the
>first
>version. How do I create a link to the second?
>
>public static void Log(string message, bool formatting = true)
>public static void Log(string message, string xmlParamFile, bool
>formatting
>= true)
>
>Thanks,
>Brian
>
>
>
>
>--
>View this message in context:
>http://doxygen.10944.n7.nabble.com/Overloaded-method-in-C-not-recognized-tp6391.html
>Sent from the Doxygen - Users mailing list archive at Nabble.com.
>
>------------------------------------------------------------------------------
>Rapidly troubleshoot problems before they affect your business. Most IT
>
>organizations don't have a clear picture of how application performance
>
>affects their revenue. With AppDynamics, you get 100% visibility into
>your 
>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>AppDynamics Pro!
>http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>_______________________________________________
>Doxygen-users mailing list
>Dox...@li...
>https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] Alias defgroup?

[Ron W. <ron...@gm...>]

On Wed, Nov 27, 2013 at 7:12 AM, <
dox...@li...> wrote:

> Date: Tue, 26 Nov 2013 15:43:27 -0800
> From: mathog <ma...@ca...>
>
> Part 1:
>
> This defgroup is defined (it is for a type of metafile) in file uemf.h:
>
> /** \defgroup U_EMF_LOGBRUSH_lbStyle_Qualifiers EMF LB_Style Enumeration
>    For U_LOGBRUSH lbStyle field
>    EMF manual 2.2.20
>    @{
> */
> #define U_BS_SOLID         0 //!< Solid brush.
> ...
> /** @} */
>
> For a different type of metafile the same values are referred to in
> uwmf.h as:
>
> /*  BrushStyle Enumeration                WMF manual 2.1.1.4
>    Same as "EMF LB_Style Enumeration" in uemf.h
> */
>
> and the functions that use those bits have comment lines like:
>
>      uint16_t            Style;              //!< BrushStyle enumeration
>
> So how does one tell Doxygen that "BrushStyle Enumeration" as some sort
> of alias
> for the first enumeration?  In most of these cases there are no extra
> defines to
> put in the include file.
>
Your enumeration could be expressed as an "enum" type, optionally using one
or more "typedef"s to declare variables that use the enumeration.

Example:

//! Base enumeraton for brush styles
enum BrushStyle_e {
U_BS_SOLID,          //!< Solid brush
U_BS_NULL,            //!< Null brush
};
// types derived from base brush style enumeration:
typedef enum BrushStyle_e EMF_Style;  //!< EMF brush style enumeration, EMF
manual 2.2.20
typedef enum BrushStyle_e WMF_Style; //!< WMF brush style enumeration, WMF
manual 2.1.1.4 (same as EMF style)
// variables using the derived brush style types:
EMF_Style EMF_Brush;   //!< Current EMF brush style
WMF_Style WMF_Brush; //!< Current WMF brush style

If your enumerated values do not start with 0, you can specify the initial
value:

enum otherStyle_e {
OTHER_SOLID = 1,
OTHER_NULL,
};

If your values are not consequtive, you can specify the value of each enum
symbol.



> Part 2.
> In some cases there are slight differences between the two defgroups.
> For instance the
> one for WMF might have a few more values, or a few less.  Is there some
> way to indicate this, short of duplicating the defgroup?
>
If one group is a proper superset of the other group, you can just use a
single
"master" enum enumeration.

If not, you can define the second in terms of the first, supplying values
for the
non-common symbols:

enum otherStyle_e {
OTHER_SOLID = U_BS_SOLID,
OTHER_NULL   = U_BS_NULL,
OTHER_DIFF    = 3,
};

[Doxygen-users] Overloaded method in C# not recognized

[Brian B. <Bri...@Ve...>]

What should be in [Log](@ref ??) so Doxygen creates a link to the overloaded
method (second one below)? A simple Log (without @ref) goes to the first
version. How do I create a link to the second?

public static void Log(string message, bool formatting = true)
public static void Log(string message, string xmlParamFile, bool formatting
= true)

Thanks,
Brian




--
View this message in context: http://doxygen.10944.n7.nabble.com/Overloaded-method-in-C-not-recognized-tp6391.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] Missing "refman" tex file for PDF output generation

[Hugo B. <hbo...@gm...>]

Thank you all, guys.

I got it, finally! After a lot of efforts, I just realized that my doxygen
version could be a little out-dated.
I checked it and I was using version 1.8.1.2 and the latest stable release
was 1.8.5.
After reinstalling my doxygen (updating to 1.8.5) I could finally generate
my latex documentation including the famous refmain.tex :)
It was an issue that were fixed between those two versions (from 1.8.1.2 to
1.8.5) after all.

I got some minor issues about file encodings when doing a 'make pdf', but
it's something that I can work on. I think I can finally get my pdf from
here.

Thank you.
Really grateful,
Hugo Benício.


On Tue, Nov 26, 2013 at 6:33 PM, <Dam...@lt...> wrote:

> For Linux users, the 'wc' shell command will say if there are non-ASCII
> characters.
> - Damon
>
>
>
>   From:       Arthur Schwarz <asc...@at...>
>
>   To:         Hugo Benicio <hbo...@gm...>, Dimitri van Heesch <
> do...@gm...>
>
>   Cc:         "dox...@li... List" <
> dox...@li...>
>
>   Date:       11/26/2013 04:06 PM
>
>   Subject:    Re: [Doxygen-users] Missing "refman" tex file for PDF output
>      generation
>
>
>
>
>
>
>
>
> If you're searching for single non-ASCII characters let me suggest that you
> write a simple program to check for them. Nothing fancy, maybe something
> like (in C):
>
> #include <stdio.h>
> void SimpleProgram(char* filename) {
>     FILE* stdin = fopen(filename, 'r');
>     int chr;
>     while( chr = fgetc(stdin) ) {
>         if (chr < ' ') {
>             switch(chr) {
>                 case '\n':
>                 case '\t':
>                 case '\r':
>                     break;
>                 default: {
>                   // tsk, tsk
>
>                 }
>
>             }
>
>         else if (chr > '~') {
>             // bad, bad boy
>
>         }
>
>     }
>
> }
>
> This is ugly code (in C or a C++ equivalent). But it's cheep to write, easy
> to debug, and (I believe) will work. The checking each file is time
> consuming (not that I haven't done it or won't continue to do it). But if
> you have many files and searching for a known fault, a filter is probably
> better.
>
> NOTE: THIS IS NOT GOOD CODE. There are much faster and cleaner ways to
> filter.
>
>
> art
> ________________________________
>
>
>
>
> Really thanks for all the anwsers
>
> @Robert
> Really good point. I'll take a look at it. My project is pretty large,
> though. But it's worth a try, definitely.
> Let's see if I find a file with non visible characters like yours.
>
> @Wendell
> I did it, but, as I said, my "make" command fails with the some errors
> telling that refmain.tex is missing (it's the root latex file supposed to
> be generated by doxygen).
>
> @Dimitri
> No, my layout_file flag points to nothing
> LAYOUT_FILE            =
>
> I'm trying robert's suggestion tomorrow. If I discover what is going wrong
> with nice self-contained examples, I'll be glad to report it on bugzilla.
> Let's see what I get then...
>
> Thanks to all,
> Hugo Benício.
>
>
>
> On Tue, Nov 26, 2013 at 5:13 PM, Dimitri van Heesch <do...@gm...>
> wrote:
>
> Hi Hugo,
> >
> >Doxygen should always generate a refman.tex file in the latex output
> directory.
> >Are you using a custom layout file (non-empty LAYOUT_FILE option)?
> >If you can capture the behaviour you see in a small self-contained example
> (=source+config file in a tar or zip) then
> >please file a bug report for it here:
> https://bugzilla.gnome.org/enter_bug.cgi?product=doxygen
> >
> >Regards,
> >  Dimitri
> >
> >
> >On 26 Nov 2013, at 20:40 , Hugo Benicio <hbo...@gm...> wrote:
> >
> >> Anyone?
> >> I really need to generate a pdf documentation but, without any error
> messages and help from here, It will be almost impossible for me,
> unfortunately...
> >>
> >> PS.: My doxy file flags relative to Latex/PDF Generation
> >>
> >> GENERATE_LATEX         = YES
> >> USE_PDFLATEX           = YES
> >>
> >>
> >> On Fri, Nov 22, 2013 at 2:52 PM, Hugo Benicio <hbo...@gm...>
> wrote:
> >> Hi all!
> >>
> >> I'm trying to generate a PDF documentation of our project here.
> >> What is going wrong is that when Latex output is generated, no
> "refman.tex" file is generated.
> >> Apparently there were no errors on doxygen log (only warnings).
> >>
> >> This is the doxygen log: http://justpaste.it/dnt7
> >>
> >> and after a "make pdf" command, I get the following:
> >> c:\SIGA\trunk\docs\doxygen\latex>pdflatex refman
> >> This is pdfTeX, Version 3.1415926-2.4-1.40.13 (MiKTeX 2.9)
> >> entering extended mode
> >> ! I can't find file `refman'.
> >> <*> refman
> >>
> >> pdflatex couldn't find 'refman' because it doesn't exist. Doxygen
> couldn't generate it for some mysterious reason I don't know why.
> >>
> >> Any clues about that?
> >>
> >> Thanks in advance,
> >> Hugo Benício.
> >>
> >>
> >
> >>
>
> ------------------------------------------------------------------------------
>
> >> Rapidly troubleshoot problems before they affect your business. Most IT
> >> organizations don't have a clear picture of how application performance
> >> affects their revenue. With AppDynamics, you get 100% visibility into
> your
> >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> >>
>
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________
>
> >> Doxygen-users mailing list
> >> Dox...@li...
> >> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> >
> >
>
>
> ------------------------------------------------------------------------------
>
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>
> ------------------------------------------------------------------------------
>
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>
>
>

[Doxygen-users] Alias defgroup?

[mathog <ma...@ca...>]

Part 1:

This defgroup is defined (it is for a type of metafile) in file uemf.h:

/** \defgroup U_EMF_LOGBRUSH_lbStyle_Qualifiers EMF LB_Style Enumeration
   For U_LOGBRUSH lbStyle field
   EMF manual 2.2.20
   @{
*/
#define U_BS_SOLID         0 //!< Solid brush.
#define U_BS_NULL          1 //!< Null brush.
#define U_BS_HOLLOW        1 //!< Hollow brush.
#define U_BS_HATCHED       2 //!< Hatched brush.
#define U_BS_PATTERN       3 //!< Pattern brush.
#define U_BS_INDEXED       4 //!< Indexed brush.
#define U_BS_DIBPATTERN    5 //!< Dibpattern brush.
#define U_BS_DIBPATTERNPT  6 //!< Dibpatternpt brush.
#define U_BS_PATTERN8X8    7 //!< Pattern 8x8 brush.
#define U_BS_DIBPATTERN8X8 8 //!< Dibpattern 8x8 brush.
#define U_BS_MONOPATTERN   9 //!< Monopattern brush.
/** @} */

For a different type of metafile the same values are referred to in 
uwmf.h as:

/*  BrushStyle Enumeration                WMF manual 2.1.1.4
   Same as "EMF LB_Style Enumeration" in uemf.h
*/

and the functions that use those bits have comment lines like:

     uint16_t            Style;              //!< BrushStyle enumeration

So how does one tell Doxygen that "BrushStyle Enumeration" as some sort 
of alias
for the first enumeration?  In most of these cases there are no extra 
defines to
put in the include file.

Part 2.
In some cases there are slight differences between the two defgroups.  
For instance the
one for WMF might have a few more values, or a few less.  Is there some 
way to indicate this, short of duplicating the defgroup?

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Doxygen-users] Missing "refman" tex file for PDF output generation

[<Dam...@lt...>]

For Linux users, the 'wc' shell command will say if there are non-ASCII
characters.
- Damon


                                                                                                                                                    
  From:       Arthur Schwarz <asc...@at...>                                                                                                 
                                                                                                                                                    
  To:         Hugo Benicio <hbo...@gm...>, Dimitri van Heesch <do...@gm...>                                                           
                                                                                                                                                    
  Cc:         "dox...@li... List" <dox...@li...>                                                      
                                                                                                                                                    
  Date:       11/26/2013 04:06 PM                                                                                                                   
                                                                                                                                                    
  Subject:    Re: [Doxygen-users] Missing "refman" tex file for PDF output	generation                                                          
                                                                                                                                                    







If you're searching for single non-ASCII characters let me suggest that you
write a simple program to check for them. Nothing fancy, maybe something
like (in C):

#include <stdio.h>
void SimpleProgram(char* filename) {
    FILE* stdin = fopen(filename, 'r');
    int chr;
    while( chr = fgetc(stdin) ) {
        if (chr < ' ') {
            switch(chr) {
                case '\n':
                case '\t':
                case '\r':
                    break;
                default: {
                  // tsk, tsk

                }

            }

        else if (chr > '~') {
            // bad, bad boy

        }

    }

}

This is ugly code (in C or a C++ equivalent). But it's cheep to write, easy
to debug, and (I believe) will work. The checking each file is time
consuming (not that I haven't done it or won't continue to do it). But if
you have many files and searching for a known fault, a filter is probably
better.

NOTE: THIS IS NOT GOOD CODE. There are much faster and cleaner ways to
filter.


art
________________________________




Really thanks for all the anwsers

@Robert
Really good point. I'll take a look at it. My project is pretty large,
though. But it's worth a try, definitely.
Let's see if I find a file with non visible characters like yours.

@Wendell
I did it, but, as I said, my "make" command fails with the some errors
telling that refmain.tex is missing (it's the root latex file supposed to
be generated by doxygen).

@Dimitri
No, my layout_file flag points to nothing
LAYOUT_FILE            =

I'm trying robert's suggestion tomorrow. If I discover what is going wrong
with nice self-contained examples, I'll be glad to report it on bugzilla.
Let's see what I get then...

Thanks to all,
Hugo Benício.



On Tue, Nov 26, 2013 at 5:13 PM, Dimitri van Heesch <do...@gm...>
wrote:

Hi Hugo,
>
>Doxygen should always generate a refman.tex file in the latex output
directory.
>Are you using a custom layout file (non-empty LAYOUT_FILE option)?
>If you can capture the behaviour you see in a small self-contained example
(=source+config file in a tar or zip) then
>please file a bug report for it here:
https://bugzilla.gnome.org/enter_bug.cgi?product=doxygen
>
>Regards,
>  Dimitri
>
>
>On 26 Nov 2013, at 20:40 , Hugo Benicio <hbo...@gm...> wrote:
>
>> Anyone?
>> I really need to generate a pdf documentation but, without any error
messages and help from here, It will be almost impossible for me,
unfortunately...
>>
>> PS.: My doxy file flags relative to Latex/PDF Generation
>>
>> GENERATE_LATEX         = YES
>> USE_PDFLATEX           = YES
>>
>>
>> On Fri, Nov 22, 2013 at 2:52 PM, Hugo Benicio <hbo...@gm...>
wrote:
>> Hi all!
>>
>> I'm trying to generate a PDF documentation of our project here.
>> What is going wrong is that when Latex output is generated, no
"refman.tex" file is generated.
>> Apparently there were no errors on doxygen log (only warnings).
>>
>> This is the doxygen log: http://justpaste.it/dnt7
>>
>> and after a "make pdf" command, I get the following:
>> c:\SIGA\trunk\docs\doxygen\latex>pdflatex refman
>> This is pdfTeX, Version 3.1415926-2.4-1.40.13 (MiKTeX 2.9)
>> entering extended mode
>> ! I can't find file `refman'.
>> <*> refman
>>
>> pdflatex couldn't find 'refman' because it doesn't exist. Doxygen
couldn't generate it for some mysterious reason I don't know why.
>>
>> Any clues about that?
>>
>> Thanks in advance,
>> Hugo Benício.
>>
>>
>
>>
------------------------------------------------------------------------------

>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into
your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
>>
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________

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

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

Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Doxygen-users mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-users

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

Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Doxygen-users mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] Missing "refman" tex file for PDF output generation

[Arthur S. <asc...@at...>]

If you're searching for single non-ASCII characters let me suggest that you write a simple program to check for them. Nothing fancy, maybe something like (in C):

#include <stdio.h>
void SimpleProgram(char* filename) {
    FILE* stdin = fopen(filename, 'r');
    int chr;
    while( chr = fgetc(stdin) ) {
        if (chr < ' ') {
            switch(chr) {
                case '\n':
                case '\t':
                case '\r':
                    break;
                default: {
                  // tsk, tsk

                }

            }

        else if (chr > '~') {
            // bad, bad boy

        }

    }

}

This is ugly code (in C or a C++ equivalent). But it's cheep to write, easy to debug, and (I believe) will work. The checking each file is time consuming (not that I haven't done it or won't continue to do it). But if you have many files and searching for a known fault, a filter is probably better.

NOTE: THIS IS NOT GOOD CODE. There are much faster and cleaner ways to filter.


art
________________________________




Really thanks for all the anwsers

@Robert
Really good point. I'll take a look at it. My project is pretty large, though. But it's worth a try, definitely.
Let's see if I find a file with non visible characters like yours.

@Wendell
I did it, but, as I said, my "make" command fails with the some errors telling that refmain.tex is missing (it's the root latex file supposed to be generated by doxygen).

@Dimitri
No, my layout_file flag points to nothing
LAYOUT_FILE            = 

I'm trying robert's suggestion tomorrow. If I discover what is going wrong with nice self-contained examples, I'll be glad to report it on bugzilla. Let's see what I get then...

Thanks to all,
Hugo Benício.



On Tue, Nov 26, 2013 at 5:13 PM, Dimitri van Heesch <do...@gm...> wrote:

Hi Hugo,
>
>Doxygen should always generate a refman.tex file in the latex output directory.
>Are you using a custom layout file (non-empty LAYOUT_FILE option)?
>If you can capture the behaviour you see in a small self-contained example (=source+config file in a tar or zip) then
>please file a bug report for it here: https://bugzilla.gnome.org/enter_bug.cgi?product=doxygen
>
>Regards,
>  Dimitri
>
>
>On 26 Nov 2013, at 20:40 , Hugo Benicio <hbo...@gm...> wrote:
>
>> Anyone?
>> I really need to generate a pdf documentation but, without any error messages and help from here, It will be almost impossible for me, unfortunately...
>>
>> PS.: My doxy file flags relative to Latex/PDF Generation
>>
>> GENERATE_LATEX         = YES
>> USE_PDFLATEX           = YES
>>
>>
>> On Fri, Nov 22, 2013 at 2:52 PM, Hugo Benicio <hbo...@gm...> wrote:
>> Hi all!
>>
>> I'm trying to generate a PDF documentation of our project here.
>> What is going wrong is that when Latex output is generated, no "refman.tex" file is generated.
>> Apparently there were no errors on doxygen log (only warnings).
>>
>> This is the doxygen log: http://justpaste.it/dnt7
>>
>> and after a "make pdf" command, I get the following:
>> c:\SIGA\trunk\docs\doxygen\latex>pdflatex refman
>> This is pdfTeX, Version 3.1415926-2.4-1.40.13 (MiKTeX 2.9)
>> entering extended mode
>> ! I can't find file `refman'.
>> <*> refman
>>
>> pdflatex couldn't find 'refman' because it doesn't exist. Doxygen couldn't generate it for some mysterious reason I don't know why.
>>
>> Any clues about that?
>>
>> Thanks in advance,
>> Hugo Benício.
>>
>>
>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________
>> Doxygen-users mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Doxygen-users mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] Doxygen-users Digest, Vol 90, Issue 8

[Ron W. <ron...@gm...>]

On Tue, Nov 26, 2013 at 3:09 PM, <
dox...@li...> wrote:

> Date: Tue, 26 Nov 2013 17:40:18 -0200
> From: Hugo Benicio <hbo...@gm...>
> Subject: Re: [Doxygen-users] Missing "refman" tex file for PDF output
>         generation
> To: dox...@li...
> Message-ID:
>         <
> CAK...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Anyone?
> I really need to generate a pdf documentation but, without any error
> messages and help from here, It will be almost impossible for me,
> unfortunately...
>
In addition to Robert Smigielski's suggestion, have you tried generating
other output formats? Are they generted correctly? If not, the location(s)
of the problems could help you find your issue.

Also, as a work-around, there are tools to convert RTF to PDF (or even HTML
to PDF). If you wanted/needed more control, is also possible to convert XML
to PDF, but that would require creating an XSL template.

Re: [Doxygen-users] Missing "refman" tex file for PDF output generation

[Hugo B. <hbo...@gm...>]

Really thanks for all the anwsers

@Robert
Really good point. I'll take a look at it. My project is pretty large,
though. But it's worth a try, definitely.
Let's see if I find a file with non visible characters like yours.

@Wendell
I did it, but, as I said, my "make" command fails with the some errors
telling that refmain.tex is missing (it's the root latex file supposed to
be generated by doxygen).

@Dimitri
No, my layout_file flag points to nothing
LAYOUT_FILE            =
I'm trying robert's suggestion tomorrow. If I discover what is going wrong
with nice self-contained examples, I'll be glad to report it on bugzilla.
Let's see what I get then...

Thanks to all,
Hugo Benício.


On Tue, Nov 26, 2013 at 5:13 PM, Dimitri van Heesch <do...@gm...>wrote:

> Hi Hugo,
>
> Doxygen should always generate a refman.tex file in the latex output
> directory.
> Are you using a custom layout file (non-empty LAYOUT_FILE option)?
> If you can capture the behaviour you see in a small self-contained example
> (=source+config file in a tar or zip) then
> please file a bug report for it here:
> https://bugzilla.gnome.org/enter_bug.cgi?product=doxygen
>
> Regards,
>   Dimitri
>
> On 26 Nov 2013, at 20:40 , Hugo Benicio <hbo...@gm...> wrote:
>
> > Anyone?
> > I really need to generate a pdf documentation but, without any error
> messages and help from here, It will be almost impossible for me,
> unfortunately...
> >
> > PS.: My doxy file flags relative to Latex/PDF Generation
> >
> > GENERATE_LATEX         = YES
> > USE_PDFLATEX           = YES
> >
> >
> > On Fri, Nov 22, 2013 at 2:52 PM, Hugo Benicio <hbo...@gm...>
> wrote:
> > Hi all!
> >
> > I'm trying to generate a PDF documentation of our project here.
> > What is going wrong is that when Latex output is generated, no
> "refman.tex" file is generated.
> > Apparently there were no errors on doxygen log (only warnings).
> >
> > This is the doxygen log: http://justpaste.it/dnt7
> >
> > and after a "make pdf" command, I get the following:
> > c:\SIGA\trunk\docs\doxygen\latex>pdflatex refman
> > This is pdfTeX, Version 3.1415926-2.4-1.40.13 (MiKTeX 2.9)
> > entering extended mode
> > ! I can't find file `refman'.
> > <*> refman
> >
> > pdflatex couldn't find 'refman' because it doesn't exist. Doxygen
> couldn't generate it for some mysterious reason I don't know why.
> >
> > Any clues about that?
> >
> > Thanks in advance,
> > Hugo Benício.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Rapidly troubleshoot problems before they affect your business. Most IT
> > organizations don't have a clear picture of how application performance
> > affects their revenue. With AppDynamics, you get 100% visibility into
> your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________
> > Doxygen-users mailing list
> > Dox...@li...
> > https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

Re: [Doxygen-users] Missing "refman" tex file for PDF output generation

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

Hi Hugo,

Doxygen should always generate a refman.tex file in the latex output directory. 
Are you using a custom layout file (non-empty LAYOUT_FILE option)?
If you can capture the behaviour you see in a small self-contained example (=source+config file in a tar or zip) then
please file a bug report for it here: https://bugzilla.gnome.org/enter_bug.cgi?product=doxygen

Regards,
  Dimitri

On 26 Nov 2013, at 20:40 , Hugo Benicio <hbo...@gm...> wrote:

> Anyone?
> I really need to generate a pdf documentation but, without any error messages and help from here, It will be almost impossible for me, unfortunately...
> 
> PS.: My doxy file flags relative to Latex/PDF Generation
> 
> GENERATE_LATEX         = YES
> USE_PDFLATEX           = YES
> 
> 
> On Fri, Nov 22, 2013 at 2:52 PM, Hugo Benicio <hbo...@gm...> wrote:
> Hi all!
> 
> I'm trying to generate a PDF documentation of our project here.
> What is going wrong is that when Latex output is generated, no "refman.tex" file is generated.
> Apparently there were no errors on doxygen log (only warnings).
> 
> This is the doxygen log: http://justpaste.it/dnt7
> 
> and after a "make pdf" command, I get the following:
> c:\SIGA\trunk\docs\doxygen\latex>pdflatex refman
> This is pdfTeX, Version 3.1415926-2.4-1.40.13 (MiKTeX 2.9)
> entering extended mode
> ! I can't find file `refman'.
> <*> refman
> 
> pdflatex couldn't find 'refman' because it doesn't exist. Doxygen couldn't generate it for some mysterious reason I don't know why.
> 
> Any clues about that?
> 
> Thanks in advance,
> Hugo Benício.
> 
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] Missing "refman" tex file for PDF output generation

[Smigielski, R. L (Robert) <Rob...@ls...>]

I have had problems where Doxygen tool cannot generate the refman output file due to an error. I found that I could reduce the set of input files to a smaller and smaller set until it could produce the refman file and then the PDF from that. That can point you to a file that is the root of the problem. A few years ago, on two files from the same developer I had non-printable non visible characters in the *.h file that somehow broke the Doxygen build process. Once I got to the point that a single file had the problem I ran a diff on the file against the previous version(s) and eventually found the non-printable characters in the file. I deleted those and the problem was resolved.
Hope this helps.

Robert Smigielski
Network Storage Products Group
LSI Corporation
1110 American Parkway NE
Allentown Pa 18109, USA
TEL 610.712.8906
rob...@ls...<mailto:rob...@ls...>

From: Hugo Benicio [mailto:hbo...@gm...]
Sent: Tuesday, November 26, 2013 2:40 PM
To: dox...@li...
Subject: Re: [Doxygen-users] Missing "refman" tex file for PDF output generation

Anyone?
I really need to generate a pdf documentation but, without any error messages and help from here, It will be almost impossible for me, unfortunately...

PS.: My doxy file flags relative to Latex/PDF Generation

GENERATE_LATEX         = YES
USE_PDFLATEX           = YES

On Fri, Nov 22, 2013 at 2:52 PM, Hugo Benicio <hbo...@gm...<mailto:hbo...@gm...>> wrote:
Hi all!

I'm trying to generate a PDF documentation of our project here.
What is going wrong is that when Latex output is generated, no "refman.tex" file is generated.
Apparently there were no errors on doxygen log (only warnings).

This is the doxygen log: http://justpaste.it/dnt7

and after a "make pdf" command, I get the following:
c:\SIGA\trunk\docs\doxygen\latex>pdflatex refman
This is pdfTeX, Version 3.1415926-2.4-1.40.13 (MiKTeX 2.9)
entering extended mode
! I can't find file `refman'.
<*> refman

pdflatex couldn't find 'refman' because it doesn't exist. Doxygen couldn't generate it for some mysterious reason I don't know why.

Any clues about that?

Thanks in advance,
Hugo Benício.

Re: [Doxygen-users] Missing "refman" tex file for PDF output generation

[Hugo B. <hbo...@gm...>]

Anyone?
I really need to generate a pdf documentation but, without any error
messages and help from here, It will be almost impossible for me,
unfortunately...

PS.: My doxy file flags relative to Latex/PDF Generation

GENERATE_LATEX         = YES
USE_PDFLATEX           = YES


On Fri, Nov 22, 2013 at 2:52 PM, Hugo Benicio <hbo...@gm...> wrote:

> Hi all!
>
> I'm trying to generate a PDF documentation of our project here.
> What is going wrong is that when Latex output is generated, no
> "refman.tex" file is generated.
> Apparently there were no errors on doxygen log (only warnings).
>
> This is the doxygen log: http://justpaste.it/dnt7
>
> and after a "make pdf" command, I get the following:
> c:\SIGA\trunk\docs\doxygen\latex>pdflatex refman
> This is pdfTeX, Version 3.1415926-2.4-1.40.13 (MiKTeX 2.9)
> entering extended mode
> ! I can't find file `refman'.
> <*> refman
>
> pdflatex couldn't find 'refman' because it doesn't exist. Doxygen couldn't
> generate it for some mysterious reason I don't know why.
>
> Any clues about that?
>
> Thanks in advance,
> Hugo Benício.
>
>

Re: [Doxygen-users] one document paragraph for N types set by typedef struct?

[mathog <ma...@ca...>]

On 25-Nov-2013 12:54, mathog wrote:
Note that when

   DISTRIBUTE_GROUP_DOC = yes

and

/**
     Draw figure
*/
typedef struct foobar {
      U_EMR               emr;                //!< U_EMR
      U_RECTL             rclBounds;          //!< bounding rectangle in
device units
      U_NUM_POINTL        cptl;               //!< Number of points to 
draw
      U_POINTL            aptl[1];            //!< array of points
} U_EMRPOLYBEZIER,
    U_EMRPOLYGON,
    U_EMRPOLYLINE,
    U_EMRPOLYBEZIERTO,
    U_EMRPOLYLINETO;

Doxygen creates this:

typedef struct U_EMRPOLYBEZIER 	U_EMRPOLYGON
typedef struct U_EMRPOLYBEZIER 	U_EMRPOLYLINE
typedef struct U_EMRPOLYBEZIER 	U_EMRPOLYBEZIERTO
typedef struct U_EMRPOLYBEZIER 	U_EMRPOLYLINETO
                 ^ link           ^ plain text

and this

struct  	U_EMRPOLYBEZIER
                  ^ link

which is all fine, but also this:

                  link (back to this location in the file)
#define 	U_EMR_POLYBEZIER   2
  	U_EMRPOLYBEZIER record.
         ^ link to the struct
                 v link (back to this location in the file)
#define 	U_EMR_POLYGON   3
  	U_EMRPOLYGON record.
         ^ text

So Doxygen is seeing the other names for that typedef struct, but it is 
only stuffing the first into some list that it refers to later, 
resulting in the "text" entries that would otherwise be links.

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Doxygen-users] one document paragraph for N types set by typedef struct?

[mathog <ma...@ca...>]

On 23-Nov-2013 02:35, Albert wrote:
> David,
> 
> Please have a look at DISTRIBUTE_GROUP_DOC set to yes and the grouping
> possibilities by using @{ and @}
> The following looks like to work for me:
> /// @{
> /** Description blah blah
> */
> typedef struct names {
>      SomeStructName    field;                //!< Description of field
> } name1, name2, name3, namen;
> /// @}
> 
> 
> Note: that I had to make a named struct of it as well otherwise name1 
> would
> be used as type name and not as variable.\


Not working for me.  I have:

/** \defgroup Common_macros Common Macros
   @{
*/
// many many #defines
/** @} */

// many many typedef struct's  but no \defgroup

/**
   Draw figure
  @{
*/
typedef struct foobar {
     U_EMR               emr;                //!< U_EMR
     U_RECTL             rclBounds;          //!< bounding rectangle in 
device units
     U_NUM_POINTL        cptl;               //!< Number of points to 
draw
     U_POINTL            aptl[1];            //!< array of points
} U_EMRPOLYBEZIER,
   U_EMRPOLYGON,
   U_EMRPOLYLINE,
   U_EMRPOLYBEZIERTO,
   U_EMRPOLYLINETO;
/** @} */

When run with DISTRIBUTE_GROUP_DOC=yes it does not document the 2nd or 
later names, and
emits this odd set of errors:

emf.h:1980: warning: Member U_EMRPOLYGON (typedef) of group 
Common_macros is not documented.
emf.h:1981: warning: Member U_EMRPOLYLINE (typedef) of group 
Common_macros is not documented.
emf.h:1982: warning: Member U_EMRPOLYBEZIERTO (typedef) of group 
Common_macros is not documented.
emf.h:1983: warning: Member U_EMRPOLYLINETO (typedef) of group 
Common_macros is not documented.

This is not part of Common_macros, that seems to be firmly terminated, 
but not for doxygen, apparently.

Putting \defgroup foobar in at the top changes it to

emf.h:1980: warning: Member U_EMRPOLYGON (typedef) of group foobar is 
not documented.

but does not resolve the issue.

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Doxygen-users] doxygen refusing to not include #define in file.c

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

Hi David,

Which version of doxygen are you using?
This problem was fixed in doxygen 1.8.4, see also
https://bugzilla.gnome.org/show_bug.cgi?id=694631

Regards,
  Dimitri

On 22 Nov 2013, at 21:05 , mathog <ma...@ca...> wrote:

> Trying to get doxygen to ignore a #define, so far without success
> 
> //! \cond
> #define UNUSED(x) (void)(x)  //! \hideinitializer
> //! \endcond
> 
> and it still emits:
> 
> file.c:35: warning: Member UNUSED(x) (macro definition) of file file.c 
> is not documented.
> 
> and puts in the html for file.c:
> 
> Macros
> #define 	UNUSED(x)   (void)(x)
> 
> It does that whether or not there is any comment at all on the same line 
> as UNUSED.
> 
> This macro should not be exposed in the documentation in any way shape 
> or form, but Doxygen
> insists that it be.  Note that when an assortment of functions and 
> typedef struct's are placed between \cond and \endcond they are excluded 
> from the HTML and there are no warnings about them not being documented. 
>  It seems to be only "#define" that is unexcludable.
> 
> Thanks,
> 
> David Mathog
> ma...@ca...
> Manager, Sequence Analysis Facility, Biology Division, Caltech
> 
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing 
> conversations that shape the rapidly evolving mobile landscape. Sign up now. 
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] one document paragraph for N types set by typedef struct?

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

David,

Please have a look at DISTRIBUTE_GROUP_DOC set to yes and the grouping
possibilities by using @{ and @}
The following looks like to work for me:
/// @{
/** Description blah blah
*/
typedef struct names {
     SomeStructName    field;                //!< Description of field
} name1, name2, name3, namen;
/// @}


Note: that I had to make a named struct of it as well otherwise name1 would
be used as type name and not as variable.

Albert


On Sat, Nov 23, 2013 at 12:37 AM, mathog <ma...@ca...> wrote:

> An include file from a C program looks like this:
>
> /** Description blah blah
> */
> typedef struct {
>      SomeStructName    field;                //!< Description of field
> } name1, name2, name3, ... namen;
>
> When doxygen processes this it hooks the documentation to name1 and
> leaves
> name2 -> namen flapping in the breeze.  It issues "undocumented"
> warnings about
> name2-> namen.
>
> Making N copies of this and editing the list down to one name for each
> would resolve the Doxygen issue, but it is a lot of work.  Is there some
> magic switch to tell Doxygen that "name2 is like name1", or better yet,
> "name2->namen are like name1"?
>
> Thanks,
>
> David Mathog
> ma...@ca...
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

[Doxygen-users] one document paragraph for N types set by typedef struct?

[mathog <ma...@ca...>]

An include file from a C program looks like this:

/** Description blah blah
*/
typedef struct {
     SomeStructName    field;                //!< Description of field
} name1, name2, name3, ... namen;

When doxygen processes this it hooks the documentation to name1 and 
leaves
name2 -> namen flapping in the breeze.  It issues "undocumented" 
warnings about
name2-> namen.

Making N copies of this and editing the list down to one name for each 
would resolve the Doxygen issue, but it is a lot of work.  Is there some 
magic switch to tell Doxygen that "name2 is like name1", or better yet, 
"name2->namen are like name1"?

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

[Doxygen-users] doxygen refusing to not include #define in file.c

[mathog <ma...@ca...>]

Trying to get doxygen to ignore a #define, so far without success

//! \cond
#define UNUSED(x) (void)(x)  //! \hideinitializer
//! \endcond

and it still emits:

file.c:35: warning: Member UNUSED(x) (macro definition) of file file.c 
is not documented.

and puts in the html for file.c:

Macros
#define 	UNUSED(x)   (void)(x)

It does that whether or not there is any comment at all on the same line 
as UNUSED.

This macro should not be exposed in the documentation in any way shape 
or form, but Doxygen
insists that it be.  Note that when an assortment of functions and 
typedef struct's are placed between \cond and \endcond they are excluded 
from the HTML and there are no warnings about them not being documented. 
  It seems to be only "#define" that is unexcludable.

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech