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

Re: [Doxygen-develop] [PATCH] VHDL Component Instantiation Fixes

[Robert A. <ab...@un...>]

On 19.03.2012 20:27, Dimitri Van Heesch wrote:
> Can you send me an example that I can use to test your patch?

Yes, please find an example here
<https://sites.google.com/site/rawbdagslair/DoxygenTestProject.7z?attredirects=0&d=1>.
My example includes the VHDL instantiation bug/graph creation bug and
the XML tag file bug I posted more recently to the list.

You will have to run

old-doxygen DoxyfileB
old-doxygen DoxyfileA

new-doxygen DoxyfileB
new-doxygen DoxyfileA_Fix

srcA contains all a DFF (sub_component), a senseless inverted DFF
(sub_sub_component) and a top level entity. Instantiating
sub_sub_component in toplevel will hide sub_component in toplevel
completely depending on the order the instantiations are processed by
the parser. So you will see different results on each parse when you
switch the locations of dffA, dffNotA and dffB.

On a side note, I just noticed that detail descriptions on
instantiations don't work for some reason...

srcB is only for showcasing the XML tag file bug. It creates two groups
with "special characters" (though they aren's /that/ special...). When
you look inside docA, you will find them to be gibberish.

> I assume your maxlevel hack is used to see is a class is a direct
> base class or sub class, right?
Yes. It could be altered to be a boolean, either only direct
"inheritance" or inheritance over all levels. That what would be needed
for VHDL at least. However, I thought it might come in handy to have
control over the depth of the recursion so the abort() can be avoided by
other language parsers etc.

Regards,

Robert

[Doxygen-develop] [BUG] Tag File Parsing Issue

[Robert A. <ab...@un...>]

Hi,

I'm currently using tag files to stitch multiple documentation files
(for multiple programming languages) together.

There seem to be two bugs related to tag/xml files:

 1. Tag files are statically produced with encoding='ISO-8859-1'
    (doxygen.cpp ll.10604).
    Yet there is not one instance of a conversion function used that I
    could find that would actually convert any tag file output from the
    source input file encoding given using INPUT_ENCODING. That doesn't
    seem right!
 2. There is a bug in tagreader.cpp. Basically, QXmlSimpleReader
    (qxml.cpp) will read any XML input file according to its encoding
    stated in each file. However, the TagFileParser handler in
    tagreader.cpp will store all incoming QString (16bit) strings inside
    m_curString which is a QCString (8bit) inside bool characters
    (tagreader.cpp ll. 789).
    This effectively annihilates the correctly parsed XML source
    encoding when curString is assigned to different information
    entities, e.g. when assigning group titles in ll. 664. While I'm not
    100% sure what happens at this implicit conversion, I reckon the
    QString will be using the thread locale to convert the QCString back
    to 16bit, thus resulting in gibberish when thread locale and XML
    encoding mismatch.

As a quick fix for 2.), I changed the declaration of m_curString to
QString so no conversions take place (but there may be memory overhead
wrt explicit/implicit sharing I read?). I didn't notice any immediate
problems with this hack.

As a fix for 1.) I propose to either actually convert to ISO-8859-1 from
the INPUT_ENCODING, or just declare the XML file to be encoded using
INPUT_ENCODING. The latter would be simplest and cleanest, IMHO.

Also, please notice that 2.) cannot just be fixed by fixing 1.), since
tag files might be produced by "3rd party" software using any encoding
they wish. The quick and dirty fix for 2.) I did would probably need
some revisitation by someone who knows about the memory overhead/sharing
capabilities involved and can decide on a proper course of action.
(Which is why I'm hesitant to post a [one-line] patch...)

Regards

Robert Abel

[Doxygen-develop] [PATCH] VHDL Component Instantiation Fixes

[Robert A. <ab...@un...>]

Hi,

I noticed that component instantiations were handled improperly:

Doubly instantiated components were just hidden and not documented at
all. This resulted in wrong documentation. The original hack (keeping a
list inside the parser) might have been intended to relieve the
"inheritance graphs" of some clutter, but that did not work properly either.
Component Instances would also point to "dummy.html" instead of their
containing architecture's page. I fixed that quick and dirty as well.
Still, the whole VHDL module seems like one big hack anyway :-/

Patch is against the latest trunk.

Signed-off-by: Robert Abel <ab...@un...>

Re: [Doxygen-develop] Doxygen Performance Issues and Solutions

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

Hi Dirk,

On Mar 8, 2012, at 19:01 , Dirk Reiners wrote:

> 
> 	Hi All,
> 
> we've been struggling with doxygen's performance for a while. Generating the docs for our project (OpenSG) with the stock 1.7.4 on F14 takes about 10 hours (and that's without using dot).
> 
> So I ran the whole thing through cachegrind (don't ask me how long that took ;) and I found a few hotspots. The biggest one by far were the isAccessibleFrom and isAccessibleFromWithExpScope functions in util.cpp. They use a QDict for storing results, which requires building a string for the key every time a test is made, which is very slow. I replaced that with a little struct and the QDict with an std::vector (it is really just used as a stack), which gave a significant speed boost.
> 
> I also tried adding a cache to isAccessibleFrom, but that had some problems (it needed to be flushed a few times during the process, and I'm not sure exactly why or if I got all cases), and it did not make a very big difference in the end. It's in there, but it's easy to take out (search for USE_ISACCESSIBLEFROM_CACHE in utils.cpp and the clearIsAccessibleFromCache(); calls in doxygen.cpp).
> 
> The other big one was the creation of the PNG files for the class diagrams etc. The images doxygen creates are pretty simple and have long single color runs. On these images the brute force encoder (which is still in the code) runs quite a bit faster than the smart one that is used by default. To make things even better I added some special case code that explicitly tries to find single color runs and quickly encodes them. The resulting PNGs are slightly larger than the original ones, but the encoding is noticeably faster.
> 
> With my patches on top of the latest SVN the time goes down to ~70 minutes, or an order of magnitude less, which is still not really fast but a lot more reasonable, IMHO. :)

These are pretty impressive results! 
I'll see how I can best integrate your patch.

Regards,
  Dimitri

[Doxygen-develop] Doxygen Performance Issues and Solutions

[Dirk R. <dir...@gm...>]

	Hi All,

we've been struggling with doxygen's performance for a while. Generating the 
docs for our project (OpenSG) with the stock 1.7.4 on F14 takes about 10 hours 
(and that's without using dot).

So I ran the whole thing through cachegrind (don't ask me how long that took ;) 
and I found a few hotspots. The biggest one by far were the isAccessibleFrom and 
isAccessibleFromWithExpScope functions in util.cpp. They use a QDict for storing 
results, which requires building a string for the key every time a test is made, 
which is very slow. I replaced that with a little struct and the QDict with an 
std::vector (it is really just used as a stack), which gave a significant speed 
boost.

I also tried adding a cache to isAccessibleFrom, but that had some problems (it 
needed to be flushed a few times during the process, and I'm not sure exactly 
why or if I got all cases), and it did not make a very big difference in the 
end. It's in there, but it's easy to take out (search for 
USE_ISACCESSIBLEFROM_CACHE in utils.cpp and the clearIsAccessibleFromCache(); 
calls in doxygen.cpp).

The other big one was the creation of the PNG files for the class diagrams etc. 
The images doxygen creates are pretty simple and have long single color runs. On 
these images the brute force encoder (which is still in the code) runs quite a 
bit faster than the smart one that is used by default. To make things even 
better I added some special case code that explicitly tries to find single color 
runs and quickly encodes them. The resulting PNGs are slightly larger than the 
original ones, but the encoding is noticeably faster.

With my patches on top of the latest SVN the time goes down to ~70 minutes, or 
an order of magnitude less, which is still not really fast but a lot more 
reasonable, IMHO. :)

Patch against current SVN attached. Let me know how it works for you.

Yours

	Dirk

[Doxygen-develop] Feature request: Return EXIT_FAILURE when option WARNINGS_ARE_ERRORS = YES

[Troy W. <dr...@gm...>]

It would be useful to have Doxygen return from main() with a status
code. This would allow scripts and makefiles to raise an error if
documentation is incomplete. Similar to the gcc argument -Werror.
Currently main() just returns 0.

I've had a brief look at the Doxygen source, and have hacked in a
smelly approximation using a global 'return_value' variable that is
set to EXIT_SUCCESS by default, but changed by the functions in
message.cpp when a warning is printed. i.e. When the warning message
functions are called, the global return_value variable is set to
EXIT_FAILURE, and main() returns this variable when finished. It
works, but not particularly well! A proper implementation would
ideally stop processing at the first warning/error and return
immediately.

Re: [Doxygen-develop] how build Entry for same function name in different namespace?

[Rene Z. <r.z...@fr...>]

Hi,

the problem only occurs if the functions are added to a group with
\addtogroup. Otherwise all functions are correctly displayed in
the namespace documentation.

Any hints?

Regards
rene

[Doxygen-develop] how build Entry for same function name in different namespace?

[Rene Z. <r.z...@fr...>]

Hi,

if I have a function with the same name in different namespaces
then the generated documentation only shows the first one.

I create an Entry for each of the two functions, set the name part
to the name of the function (without the namespace part) and add
the Entry to the namespace entry.

When I look in the Doxygen::functionNameSDict I find only the first entry.
The qualifiedName() function gives the correct fully qualified name.

Is there something I can do?

Regards
rene

Re: [Doxygen-develop] Different behavior of Doxygen-1.7.5 with Fortran modules

[Davide C. <dc...@ar...>]

Hello, and sorry for coming back to this subject, but nothing has 
changed in the meantime: since version 1.7.5 Doxygen treats Fortran 
modules as classes and not as namespaces, with some unpleasant side 
effects (modules, interfaces and derived types merged in the class menu; 
no modules in the namespace menu; alphabetical sorting forced for class 
components). I propose this successfully tested patch which keeps this 
behavior as an option (FORTRAN_MODULES_AS_CLASSES = YES) while reverting 
the default to the old -IMHO more correct- behavior. Following is the 
patch, based on svn HEAD (Release-1.7.6.1-20120110) and the old 
discussion thread. Please tell me whether this is reasonable,
	Thank you and best regards, Davide.

--- config.xml~	2011-12-06 22:03:24.000000000 +0100
+++ config.xml	2012-02-03 09:32:08.000000000 +0100
@@ -369,6 +369,11 @@
  name of the file that contains the anonymous namespace. By default
  anonymous namespaces are hidden.
  ' defval='0'/>
+    <option type='bool' id='FORTRAN_MODULES_AS_CLASSES' docs='If the
+FORTRAN_MODULES_AS_CLASSES tag is set to YES, Doxygen will treat
+Fortran MODULEs as classes rather than namespaces, thus changing the
+documentation layout.
+' defval='0'/>
      <option type='bool' id='HIDE_UNDOC_MEMBERS' docs='
  If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
  undocumented members of documented classes, files or namespaces.

--- fortranscanner.l~	2012-02-03 09:16:21.000000000 +0100
+++ fortranscanner.l	2012-02-03 09:27:12.000000000 +0100
@@ -1881,7 +1881,10 @@
    //fprintf(stderr, "0=========> got module %s\n", name);

    if (isModule)
-    current->section = Entry::NAMESPACE_SEC;
+    if (Config_getBool("FORTRAN_MODULES_AS_CLASSES"))
+      current->section = Entry::CLASS_SEC;
+    else
+      current->section = Entry::NAMESPACE_SEC;
    else
      current->section = Entry::FUNCTION_SEC;


> Dear All,
>
> This change has been made some time ago. I noticed it as well, I see
> that it had a positive effect on the search functionality. I'll have
> to have a look into the deeper reasons.
>
> Best Regards,
>
> Albert
>
> On Wed, Aug 24, 2011 at 09:26, Davide Cesari <dcesari@...> wrote:
>> Hi Loic,
>>        I also noticed the issue, at least for what concerns the Fortran module
>> list, I sent this message some days ago to doxygen-develop, it seems to
>> be a design choice, not modifiable by a switch for now, but I did not
>> understand whether it was deliberate or accidental,  I got no reaction
>> up to now. For the moment I just reverted that little modification in
>> fortranscanner.l and recompiled.
>>
>> On August 18 I wrote:
>>> Hi, and thanks as always for the great work.
>>>
>>> I noticed a couple of strange things in new doxygen version when
>>> parsing Fortran documentation.
>>>
>>> The first is that now MODULEs generate classes and not namespaces as
>>> before, this is confirmed by looking at a svn diff at line 1757/1790
>>>
>>> http://doxygen.svn.sourceforge.net/viewvc/doxygen/trunk/src/fortranscanner.l?r1=762&r2=766
>>>
>>>  Is there a reason for this? IMHO a Fortran module is closer to a
>>> namespace than to a class and it can itself contain many class
>>> definitions (in the sense of struct (TYPE), interface or f2003
>>> classes), moreover I find it useful to have a separate module list
>>> under the namespace menu, although the word namespace may seem quite
>>> unusual for a Fortran programmer, but that's a different problem.
>>>
>>> Could this issue be fixed, or treated with a configuration switch, if
>>> 1.7.5 behavior is really desired by anybody?
>>>
>>> The second strange behavior is that now the brief class documentation
>>> within a module seems to be always sorted in alphabetical order
>>> regardless of the settings of SORT_BRIEF_DOCS. In fact this is
>>> connected to the previous issue that a module is a class: if
>>> reverting in fortranscanner.l CLASS_SEC => NAMESPACE_SEC the module
>>> becomes a namespace and sorting is as expected.
>>>
>>> Thank you for your attention, bye, Davide
>>
>> Il 23/08/2011 18:12, LB ha scritto:
>>>     Hi,
>>> I'm using doxygen to generate some documentation for a project in
>>> Fortran 90 on Linux.
>>> I've just updated doxygen from 1.7.1 to 1.7.5.1 and I have got now very
>>> different results :
>>>     - there is no "module list" page  anymore. The documentation for the
>>> modules seems to have merged with the "Data types list"
>>>     - there is no more 'call graph' or 'caller graph' in the function
>>> definitions defined in any module.
>>> Is-there anything to change in the configuration file to get them back ?
>>> My configuration file is simple :
>>> OPTIMIZE_FOR_FORTRAN   = YES
>>> EXTRACT_ALL            = YES
>>> EXTRACT_ALL            = YES
>>> EXTRACT_LOCAL_METHODS  = YES
>>> INTERNAL_DOCS          = YES
>>> CASE_SENSE_NAMES       = NO
>>> SORT_MEMBER_DOCS       = NO
>>> LAYOUT_FILE            = doxylayout.xml
>>> FILE_PATTERNS          = *.f90
>>> EXCLUDE_PATTERNS       = test_*
>>> INLINE_SOURCES         = YES
>>> STRIP_CODE_COMMENTS    = NO
>>> HTML_DYNAMIC_SECTIONS  = YES
>>> GENERATE_LATEX         = NO
>>> HAVE_DOT               = YES
>>> UML_LOOK               = YES
>>> TEMPLATE_RELATIONS     = YES
>>> CALL_GRAPH             = YES
>>> CALLER_GRAPH           = YES
>>> MAX_DOT_GRAPH_DEPTH    = 3
>>> DOT_MULTI_TARGETS      = YES
>>>
>>>
>> --
>> ============================= Davide Cesari ============================
>> Servizio IdroMeteoClima - ARPA Emilia Romagna
>> NWP modelling - Modellistica numerica previsionale
>>  Phone/Fax: +39 051525926/+39 0516497501
>>  E-mail:    dcesari@...
>>  Home page: http://www.webalice.it/o.drofa/davide/
>>  Address:   ARPA-SIM, Viale Silvani 6, 40122 Bologna, Italy
>> ========================================================================
>>


-- 
============================= Davide Cesari ============================
Servizio IdroMeteoClima - ARPA Emilia Romagna
NWP modelling - Modellistica numerica previsionale
  Phone/Fax: +39 051525926/+39 0516497501
  E-mail:    dc...@ar...
  Home page: http://www.webalice.it/o.drofa/davide/
  Address:   ARPA-SIM, Viale Silvani 6, 40122 Bologna, Italy
========================================================================

[Doxygen-develop] Adding support for XQuery

[William C. <wca...@gm...>]

Hello,

I would like to extend doxygen to support the XQuery language and I'm
not sure where to start.
Do we need to extend the doxygen parser to understand xquery modules?
Can we feed doxygen with some structured information about an xquery
module that doxygen can process?

Kind regards,

William

Re: [Doxygen-develop] PATCH: Exclude C++ std::string/wstring from diagrams

[Fredrik O. <for...@gm...>]

On Mon, Dec 26, 2011 at 11:59 AM, Dimitri Van Heesch <do...@gm...> wrote:

> The patch has unwanted side-effects :-(
> Parameter matching can now fail when the type is a std::string where it previously succeeded,
> so I had to remove the patch again.

Ok. That is understandable. Do you have any ideas of alternative
approaches for excluding text strings from the diagrams?


Regards,
Fredrik

Re: [Doxygen-develop] PATCH: Exclude C++ std::string/wstring from diagrams

[Fredrik O. <for...@gm...>]

On Fri, Dec 23, 2011 at 10:58 AM, Dimitri Van Heesch <do...@gm...> wrote:
>> Would it be possible to consider the STL string classes as "primitive"
>> types, and exclude them from collaboration (and possibly other)
>> diagrams?
>
> Makes sense. I'll include your patch. If anyone sees problem with it,
> please let me know.

Thank you. :-)

[Doxygen-develop] PATCH: Exclude C++ std::string/wstring from diagrams

[Fredrik O. <for...@gm...>]

The BUILTIN_STL_SUPPORT option is great for enabling doxygen to parse
C++ classes containing STL containers and smart-pointers. It does,
however, also lead to some "noise" in the diagrams; especially for
text strings. I don't personally see the big value of adding separate
boxes for e.g. std::string members in collaboration diagrams for
classes containing strings. Instead, text strings could be considered
a "primitive" type, like int, float etc.


Would it be possible to consider the STL string classes as "primitive"
types, and exclude them from collaboration (and possibly other)
diagrams?


A patch that attempts to do so is attached.

Re: [Doxygen-develop] parser and documentation question

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

On Nov 18, 2011, at 21:05 , Rene Zaumseil wrote:

> Hi,
> 
> How can we distinguish 2 ore more commands on one line
> in the generated documentation?
> 
> Currently we only have start and end line number.
> 
> p.e. in C notation (problem in documentation of Var1):
>  static int Var1; typedef struct {
>    int i;
>  } myStruct;
> 
> The code formatting fails for Var1 because of wrong syntax
> in the line:
>  static int Var1; typedef struct {


There is no way to do this now, and I don't see an easy way to add this. 
It is also rather uncommon to put multiple definitions on the same line 
(i.e. it would also be confusing for the programmer, not just doxygen)

Regards,
  Dimitri

[Doxygen-develop] parser and documentation question

[Rene Z. <r.z...@fr...>]

Hi,

How can we distinguish 2 ore more commands on one line
in the generated documentation?

Currently we only have start and end line number.

p.e. in C notation (problem in documentation of Var1):
  static int Var1; typedef struct {
    int i;
  } myStruct;

The code formatting fails for Var1 because of wrong syntax
in the line:
  static int Var1; typedef struct {


rene

[Doxygen-develop] tcl parser changes

[Rene Z. <r.z...@fr...>]

Hi,

with the attached patch the tcl parser detects 
now correctly the following cases:
  Commands starting with \ (backslash)
  Command definitions followed with any whitespace before end of line.

Regards
rene

PS. Is this the preferred way to send patches?

[Doxygen-develop] Fwd: Is there any interest in incorporating any of these changes into doxygen?

[John S. <jsc...@gm...>]

I meant to send this to the devel list, not directly to Dimitri

On Thu, Nov 10, 2011 at 6:21 PM, John Scipione <jsc...@gm...> wrote:
> On Thu, Nov 10, 2011 at 5:00 PM, Dimitri Van Heesch <do...@gm...> wrote:
> I have only looked at the html output so far. All of the CSS style
> functions (feature 2) work in html only. The implementations for the
> functions in Latex, RTF, man, etc. are blank. For the other features
> I'll have to test before submitting patches.
>
> I'm also going to have to look at a simpler example with the default
> CSS since the project that I am working with has some quite extensive
> CSS changes applied. On the bright side the Haiku API contains a lot
> of advanced C++ features like exceptions and templates and the like so
> that forced me to test those cases.

I have posted a patch and sample project to ticket 663949:

https://bugzilla.gnome.org/show_bug.cgi?id=663949

I used the TinyXML library as an example because it is small, contains
overloaded methods, and uses the default html template and CSS.

I built and tested html, latex, rtf, and man output. All build without
error and allow you to look at the output which seems to look pretty
good. I created one config file flag for the titles. It is
SHOW_MEMBER_NAMES and is turned off by default.

The patch I attached is created off the latest svn version. You should
be able to apply to patch and build the sample project to see the
changes. I also added a .memoverloads class to the default CSS to show
the overloaded methods better.

Check it out and let me know what you think.

Thanks,
John Scipione

Re: [Doxygen-develop] Is there any interest in incorporating any of these changes into doxygen?

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

Hi John,

On Nov 9, 2011, at 23:20 , John Scipione wrote:

> Hello doxygen developers,
> 
> I am working on documenting the API documentation of Haiku for the Haiku Project using doxygen. I've made a few additions to doxygen in order to support some features I'd like to have. I am wondering if there is interest in incorporating any of the changes I've made before I set off to do the work of regression testing and making proper patches.
> 
> The following screenshot demonstrates most of the changes:
> 
> http://imagebin.org/183387
> 
> The changes are as follows: (Consider all these features to be optional, you'll have to opt-in if you want them)
> 
> 0. Make a distinction between functions and methods -- methods are functions with a parent. All methods are functions but not all functions are methods. (needed for 2)
> 1. Add a title before each item in the detailed description. For functions the title gets an innertube () automatically attached.
> 2. Use CSS (for the html output) to style the above titles, class names, method names, function names, types, parameters, default values, qualifiers (like const and virtual) and punctuation. You can see in the example that I made each of these a different color.
> 3. If a method or function is overloaded show all the overloads together followed by a detailed description of each. Alphabetically sorted (via SORT_MEMBER_DOCS = YES) output is a pre-requisite for this.
> 
> Comments and questions welcome.

Not sure about 1, but the rest seems useful to me. 

Regards,
  Dimitri

[Doxygen-develop] Is there any interest in incorporating any of these changes into doxygen?

[John S. <jsc...@gm...>]

Hello doxygen developers,

I am working on documenting the API documentation of Haiku for the Haiku
Project using doxygen. I've made a few additions to doxygen in order to
support some features I'd like to have. I am wondering if there is interest
in incorporating any of the changes I've made before I set off to do the
work of regression testing and making proper patches.

The following screenshot demonstrates most of the changes:

http://imagebin.org/183387

The changes are as follows: (Consider all these features to be optional,
you'll have to opt-in if you want them)

0. Make a distinction between functions and methods -- methods are
functions with a parent. All methods are functions but not all functions
are methods. (needed for 2)
1. Add a title before each item in the detailed description. For functions
the title gets an innertube () automatically attached.
2. Use CSS (for the html output) to style the above titles, class names,
method names, function names, types, parameters, default values, qualifiers
(like const and virtual) and punctuation. You can see in the example that I
made each of these a different color.
3. If a method or function is overloaded show all the overloads together
followed by a detailed description of each. Alphabetically sorted (via
SORT_MEMBER_DOCS = YES) output is a pre-requisite for this.

Comments and questions welcome.

Thanks,
John Scipione

[Doxygen-develop] entry class question

[Rene Z. <r.z...@fr...>]

Hello,

after parsing source code I have two entry class objects.
One for the declaration of a method inside a class and one
for the definition of these method. Both entries contain
documentation extracted with parseCommentBlock().
Currently I add the doc and brief part of the
definition entry to the declaration entry.
The problem are the @bug and @todo elements.
The elements are shown in the method description but
not in the related BUG and TODO page.

And the second question.
I create namespace entries for each class entry to
put class related functions and variables into.
Sometimes there are no such functions or variables.
How can I check if the created namespace documentation
page will be empty and remove the namespace entry?

Thanks for your help.

rene

Re: [Doxygen-develop] Algorithm encoding for filename which size is greater than 128 characters

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

Hi David,

On Oct 19, 2011, at 15:23 , Francois, David wrote:

> Hi,
>  
> We need to generate the HTML file name to access the documentation for a given class or file.
>  
> What is the algorithm for encoding the HTML file name (specially for file which the name size is greater than 128 characters)?
> Example: classcom_1_1orange_1_1identity_1_1buse_1_1mediation_1_1generic_1_1applicatif_1_1transformer_1_1b1c9ae228053eafb0aa0fdc07c2b5fe82.html
>  

See function convertNameToFile() in src/utils.cpp, in particular the "long names" case.

Basically, first a number of characters are escaped (e.g. a ':' becomes '_1'), and when the resulting file name gets longer 
than 128 characters, an md5 hash is created for this name, and this is then appended to the 
first 96 characters of the name.

Regards,
  Dimitri

[Doxygen-develop] Algorithm encoding for filename which size is greater than 128 characters

[Francois, D. <dav...@lo...>]

Hi,

We need to generate the HTML file name to access the documentation for a given class or file.

What is the algorithm for encoding the HTML file name (specially for file which the name size is greater than 128 characters)?
Example: classcom_1_1orange_1_1identity_1_1buse_1_1mediation_1_1generic_1_1applicatif_1_1transformer_1_1b1c9ae228053eafb0aa0fdc07c2b5fe82.html

Thanks

Regards,

David FRANCOIS



Think green - keep it on the screen.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

[Doxygen-develop] Almost Back

[Kevin M. <dol...@ao...>]

Hello Everyone,

I previously worked with this project.  Something happened that caused 
me to stop for a few years (Dimitri has the story).  I have been able 
to salvage my GNOME Bugzilla account, which has editbugs permissions on 
it.  Currently, I use public computers and a Playstation 3 to gain 
access to the internet.  Once I get a PC in the next few months, I will 
be able to help triage some bugs in Doxygen and make a few patches for 
Dimitri to review.

Respectfully submitted,

- Kevin McBride

[Doxygen-develop] Incorrect template created for HTML_HEADER

[glpk x. <xyp...@gm...>]

With command
doxygen -w html header footer style
templates can be generated.

The header template contains a line
<link href="$relpath$style" rel="stylesheet" type="text/css" />

Hence when HTML_HEADER is set the generated HTML contains a line
<link href="style" rel="stylesheet" type="text/css" />
no matter what the value of HTML_STYLE is in the configuration file.

My expectation is that HTML_STYLE should always be observed.

Variables should not be replaced when writing templates.

The generated template should always contain a line
<link href="$relpath$$stylesheet" rel="stylesheet" type="text/css" />

Best regards

Xypron
-- 
Follow me at http://twitter.com/#!/xypron

Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: [Doxygen-develop] Problem compiling Doxygen on Linux

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

Hi Dimitri,

The flex version is 2.5.4.

Best Regards,

Albert

On Tue, Aug 30, 2011 at 20:52, Dimitri Van Heesch <do...@gm...> wrote:
> Hi Albert,
>
> On Aug 29, 2011, at 12:15 , Albert wrote:
>
>> Dear all,
>>
>> I have some problems compiling the newest doxygen code (version 775 from svn)
>> on a redhat 5 system.
>>
>> I get the following error message:
>> g++ -c -pipe -fno-exceptions -fno-rtti -DYY_TYPEDEF_YY_SIZE_T
>> -Dyy_size_t=int -D_LARGEFILE_SOURCE -Wall -W -fno-exceptions -O2
>> -I../qtools -I../libmd5 -o ../objects/ce_lex.o ce_lex.cpp
>> ce_lex.cpp:168: error: multiple types in one declaration
>> ce_lex.cpp:168: error: declaration does not declare anything
>>
>> When I look in the the ce_lex.cpp file I see:
>> typedef unsigned int yy_size_t;
>>
>> I think thgere is a problem with the -D flag as set in the compile line.
>> The compiule line is generated from:
>> ./src/libdoxygen.pro.in:TMAKE_CXXFLAGS += -DYY_TYPEDEF_YY_SIZE_T -Dyy_size_t=int
>>
>> I have removed in my version the  -Dyy_size_t=int and than everything compiles.
>
> I specifically added the -D stuff to work around a series of nasty warnings
> that appeared in the generated code, because yy_size_t was typedef'ed as a size_t
> and then compared against an int.
>
> Apparently the flex version of RedHat 5 produces different output.
> Can you tell me which version they ship? I'm using 2.5.35.
>
> Regards,
>  Dimitri