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

[Doxygen-develop] doxygen and standard C++ library

[johnk <jk...@ar...>]

Dimitri, as I work on some enhancements for Doxygen, is there any reason 
I shouldn't use std as opposed to "qtools"?  The first enhancement I 
did, some additional capabilities for markdown tables (column and row 
spans), I used std.  The PlantUML enhancements I'm working on would 
really benefit from std, but I wanted to be sure there wasn't a reason 
not to implement things that way.

Re: [Doxygen-develop] seg fault in doxygen.cpp (1.8.8 / 1.8.9.1)

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

Hi Johnk,

I've pushed this commit to deal with this in a more structural way:
https://github.com/doxygen/doxygen/commit/0831c71c05c9204839e187759f13303e64783730
(note that on most platforms printing a NULL pointer does not result in a segfault).

Regards,
  Dimitri

> On 02 Apr 2015, at 21:07 , johnk <jk...@ar...> wrote:
> 
> There are numerous debug statements in doxygen.cpp using an unchecked 
> templSpec.data() which causes seg faults.  Should be changed to:
> 
> templSpec.isEmpty()?"":templSpec.data()
> 
> 
> e.g.
>           Debug::print(Debug::Classes,0,
>                        "    New undocumented base class `%s' 
> baseClassName=%s templSpec=%s isArtificial=%d\n",
> biName.data(),baseClassName.data(),templSpec.data(),isArtificial
>                       );
> 
> 
> becomes
> 
> 
>           Debug::print(Debug::Classes,0,
>                        "    New undocumented base class `%s' 
> baseClassName=%s templSpec=%s isArtificial=%d\n",
> biName.data(),baseClassName.data(),templSpec.isEmpty()?"":templSpec.data(),isArtificial
>                       );
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] seg fault in doxygen.cpp (1.8.8 / 1.8.9.1)

[johnk <jk...@ar...>]

There are numerous debug statements in doxygen.cpp using an unchecked 
templSpec.data() which causes seg faults.  Should be changed to:

templSpec.isEmpty()?"":templSpec.data()


e.g.
           Debug::print(Debug::Classes,0,
                        "    New undocumented base class `%s' 
baseClassName=%s templSpec=%s isArtificial=%d\n",
biName.data(),baseClassName.data(),templSpec.data(),isArtificial
                       );


becomes


           Debug::print(Debug::Classes,0,
                        "    New undocumented base class `%s' 
baseClassName=%s templSpec=%s isArtificial=%d\n",
biName.data(),baseClassName.data(),templSpec.isEmpty()?"":templSpec.data(),isArtificial
                       );

[Doxygen-develop] Working on adding PlantUML class diagrams

[johnk <jk...@ar...>]

I'm interested in (and have started) modifying the Doxygen code to allow 
for the generation of class diagrams using PlantUML, but I wanted to get 
some input before I got too far in.

My current thinking is just to have the diagrams generated as an aside 
to the Graphviz diagrams.  I mostly wanted a tool to automatically 
generate nice UML class diagrams from my code.  I'm already using 
Doxygen and it has a framework for doing this already. PlantUML does not 
support image mapping so the nice links that are generated in Graphviz 
simply aren't available.

That said, others probably have a different opinion on how best to 
utilize PlantUML.  As such, I'm open to suggestions as to how best to 
utilize the tool inside Doxygen (beyond the already available embedded 
diagrams).

I should probably mention that I'm only inclined to add support for 
PlantUML class diagrams - it's not really suited for the other types of 
diagrams that Doxygen generates.

Re: [Doxygen-develop] sqlite implementation

[Adrian M N. <gr...@gm...>]

On Sun, Mar 29, 2015 at 7:50 PM, Travis Everett <tra...@gm...>
wrote:

> Hi all,
>
> I was excited to see the sqlite generator addition back in 1.8.4, as I was
> struggling with the clunkiness of trying to integrate the in-game developer
> documentation system for a MUD I admin for with doxygen's XML output.
> Unfortunately when I took a look at what was being stored in sqlite, it
> wasn't a step up from what we could get by parsing the xml, so I put the
> project on hold to see if better support would turn up. It seems like
> progress on the implementation has been languishing for the past year, so
> I've been taking a more serious look at what information's being stored,
> and how much work it'll take to push the existing implementation forward to
> fit our use case (a slow process, since I haven't worked on doxygen before,
> or even written any C++ in the last ~12 years...)
>
> At first I thought this might just be a matter of extending support for
> groups and pages, but as I've been getting my hands dirty I've found a
> number of issues that suggest that the current implementation probably
> isn't using an ideal schema or data model. For example, because we have a
> lot of inheritance relationships documented, our memberdef table has 87100
> total records, 70545 of which are duplicates of 3197 unique members that
> differ only in rowid. I'm hoping to get a sense of whether anyone here:
> - already has substantive work done on issues with this implementation
> that hasn't worked its way upstream to the doxygen repo yet
> - is actually using it for something non-trivial (and whether you're using
> workarounds to do so)
>
> Just hoping to get a sense of whether I am or can avoid reinventing the
> wheel, and how much resistance there will be to schema changes.
>

Hi,

I do have something on the uniqueness of the rows, but I have to dig
through my branches.
As for clients of sqlite3 backend, search.py and dynamic tooltips (through
CGI) are the current clients of the sqlite3 backend.

If you can come up with a schema that works for you, in sqlite3, I'm ok
with that.

[Doxygen-develop] sqlite implementation

[Travis E. <tra...@gm...>]

Hi all,

I was excited to see the sqlite generator addition back in 1.8.4, as I was
struggling with the clunkiness of trying to integrate the in-game developer
documentation system for a MUD I admin for with doxygen's XML output.
Unfortunately when I took a look at what was being stored in sqlite, it
wasn't a step up from what we could get by parsing the xml, so I put the
project on hold to see if better support would turn up. It seems like
progress on the implementation has been languishing for the past year, so
I've been taking a more serious look at what information's being stored,
and how much work it'll take to push the existing implementation forward to
fit our use case (a slow process, since I haven't worked on doxygen before,
or even written any C++ in the last ~12 years...)

At first I thought this might just be a matter of extending support for
groups and pages, but as I've been getting my hands dirty I've found a
number of issues that suggest that the current implementation probably
isn't using an ideal schema or data model. For example, because we have a
lot of inheritance relationships documented, our memberdef table has 87100
total records, 70545 of which are duplicates of 3197 unique members that
differ only in rowid. I'm hoping to get a sense of whether anyone here:
- already has substantive work done on issues with this implementation that
hasn't worked its way upstream to the doxygen repo yet
- is actually using it for something non-trivial (and whether you're using
workarounds to do so)

Just hoping to get a sense of whether I am or can avoid reinventing the
wheel, and how much resistance there will be to schema changes.

Cheers,
Travis

[Doxygen-develop] Possible bug in writeDotImageMapFromFile()

[Stormont, B. <BSt...@ze...>]

Hi,

While using the \dot and \dotfile commands, I ran across a potential bug in writeDotImageMapFromFile() in dot.cpp.  The following is a snippet of the existing code:


  if (imgExt=="svg") // vector graphics

  {

    //writeSVGFigureLink(t,relPath,inFile,inFile+".svg");

    //DotFilePatcher patcher(inFile+".svg");

    QCString svgName=outDir+"/"+baseName+".svg";

    writeSVGFigureLink(t,relPath,baseName,svgName);

    DotFilePatcher patcher(svgName);

    patcher.addSVGConversion(relPath,TRUE,context,TRUE,graphId);

    patcher.run();

  }

Note that the SVG file link is created *before* the SVG file is patched with the svgpan.js support.   As a result, for any \dot or \dotfile that has a resulting large size, the iframe link generated by writeSVGFigureLink() will be forced to the actual dimensions of the SVG (potentially thousands of pixels wide), so the svgpan.js will not provide any useful functionality and viewing the resulting embedded SVG is unwieldy.

Moving the writeSVGFigureLink() to *after* the call to patcher.run() produces better HTML results where the embedded SVG is put in an HTML iframe with "width=100%" rather than the original SVG width, however I wasn't sure if doing so would have any adverse effects.

Thanks,
Brian




________________________________
- CONFIDENTIAL-

This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.

Re: [Doxygen-develop] Preprocess generated .dot files

[Shashank C. <sha...@ch...>]

I've made a few minor changes to the doxygen sources to allow the user to
introduce an external preprocess step for include graph dot-file creation.

The changes are available on github at
https://github.com/chintal/doxygen/tree/dot-preprocess in case anyone is
interested. An example python script to preprocess files is at
https://github.com/chintal/dot-scripts.

Note that the changes add config options to the Doxyfile, and Doxyfiles
written to use these changes will cause warnings with standard versions of
doxygen.




On Thu, Feb 12, 2015 at 1:38 AM, Shashank Chintalagiri <sha...@ch...>
wrote:

> Hello,
>
> I've been using doxygen recently to try to document some embedded code I'm
> working on. I would like to be able to insert some custom processing code
> on the generated .dot files before they are used.
>
> I've put up a small example of what I'd like to do up at
> http://static.chintal.in/doxygen/simplify.html
>
> Is there some way to get doxygen to allow calling a script from within
> doxygen? I can't seem to find any related config options, but perhaps there
> is some plugin interface I could use or such?
>
> Thanks
> Shashank
>

[Doxygen-develop] Preprocess generated .dot files

[Shashank C. <sha...@ch...>]

Hello,

I've been using doxygen recently to try to document some embedded code I'm
working on. I would like to be able to insert some custom processing code
on the generated .dot files before they are used.

I've put up a small example of what I'd like to do up at
http://static.chintal.in/doxygen/simplify.html

Is there some way to get doxygen to allow calling a script from within
doxygen? I can't seem to find any related config options, but perhaps there
is some plugin interface I could use or such?

Thanks
Shashank

Re: [Doxygen-develop] Tutorial Message Sequence Charts with Moritz is online

[Eckard K. <eck...@t-...>]

Hello Every Body.

I forgot to mention you will find the tutorial at
https://sourceforge.net/projects/moritz/files/Moritz_2.x/DevelopmentFor_2_1_0/Snapshot_2_0_2/Tutorials/
as zip-file
  04_MessageSequence.zip

Best Regards,
                          Eckard Klotz.


Am 01.02.2015 um 15:20 schrieb Eckard Klotz:
> Hello every body
>
> As already announced last year, a first tutorial was published today 
> to show how to create message sequence charts with Moritz. As for 
> nassi shneiderman or uml like activity diagrams Moritz generates no 
> images directly but image describing scripts in this case scripts for 
> the tool msgen you will find at
>    http://www.mcternan.me.uk/mscgen/
> Mscgen is already known by Doxygen and the script-files can be added 
> to the Doxygen output by using the command mscfile .
> This first version is published to introduce the new feature of Moritz 
> that is still under development. The goal is to ask the users to take 
> a look and to post some comments in the forum at
>     http://sourceforge.net/p/moritz/discussion/
> A pdf in tutorial describes the basic steps needed to create message 
> sequence charts. The provided folder "MessageSequence_1" contains the 
> example based on the same sources as the other tutorials.
>
> Please try it out and post a comment,
> Eckard Klotz.

[Doxygen-develop] Tutorial Message Sequence Charts with Moritz is online

[Eckard K. <eck...@t-...>]

Hello every body

As already announced last year, a first tutorial was published today to 
show how to create message sequence charts with Moritz. As for nassi 
shneiderman or uml like activity diagrams Moritz generates no images 
directly but image describing scripts in this case scripts for the tool 
msgen you will find at
    http://www.mcternan.me.uk/mscgen/
Mscgen is already known by Doxygen and the script-files can be added to 
the Doxygen output by using the command mscfile .
This first version is published to introduce the new feature of Moritz 
that is still under development. The goal is to ask the users to take a 
look and to post some comments in the forum at
     http://sourceforge.net/p/moritz/discussion/
A pdf in tutorial describes the basic steps needed to create message 
sequence charts. The provided folder "MessageSequence_1" contains the 
example based on the same sources as the other tutorials.

Please try it out and post a comment,
Eckard Klotz.

[Doxygen-develop] Doxygen 1.8.9 on Win8.1 "Error: Reference source not found" in refman.rtf :-(

[Rolf H. <hem...@gm...>]

Hello,

a)
with RTF output of Doxygen 1.8.9 on english Windows 8.1, there is the 
problem in the file refman.rtf

> File Index
> 	File List
> Here is a list of all documented files with brief descriptions:
> C:/Users/Public/projects_local/hemmerling/hemmerling_pwendean_keil/src/getline.c (Line Edited Character Input for the application "Paketwendeanlage" ) 	Error: Reference source not found

while of course Doxygen was/is processing all the mentioned files, 
successfully ( as shown by the HTML output, and the logging ).

If I move the "refman.rtf" file to another *german* Windows 7, the error 
message even changes to German language "Fehler: Referenz nicht gefunden".

There is nothing special with the files, or the file location. I did not 
include special informations in the parsed files to handle the "File 
list" section.

b)
I found a description of this kind of bug here

"Don’t Let Word Get You Down, With “Error! Reference Source Not Found”
http://www.turbolaw.com/blog/2007/10/05/dont-let-word-get-you-down-with-error-reference-source-not-found/


So I would be pleased about an improved software update :-).

Sincerely
Rolf

-- 
http://www.hemmerling.com
SCADA Expertness - Quality Intensification for IT + Automation
Member of Texas Instruments Expert Advisory Panel
CeBIT Competence Store Partner

[Doxygen-develop] Doxygen 1.8.9 on Win8.1 is "swallowing" some (expected) characters in the log

[Rolf H. <hem...@gm...>]

Hello,

Some output of Doxygen 1.8.9 on Win8.1 is "missing", see

**************
> Combining RTF output...
> lookup cache used 44/65536 hits=71 misses=44
> finished...
> irq.c is not documented.
--^
There is never a file "irq.c" in the directory, but just "sioirq.c".
> C:/Users/Public/projects_local/hemmerling/hemmerling_pwendean_keil/src/sioirq.c:50: warning: Member oend (variable) of file sioirq.c is not documented.
--^
Here and everyelse, "sioirq.c" is properly displayed.
*************

This means that Doxygen at that point is "swallowing" some characters in 
the output to the log file.

Maybe it is a typical "buffer problem", as known from such legacy 
software ( 1997 was initial release according to Wikipedia ), and so 
maybe the indication of much bigger fault.

I didn´t check the Doxygen source code for the bug.
I would be pleased if you can fix it, anyhow.

** Anyhow I think Doxygen is really-great software, thanks for 
development + free license **

Sincerely
Rolf

Complete output of Doxygen:
************************************
C:/Users/Public/projects_local/hemmerling/hemmerling_pwendean_keil/src/sioirq.c:37: 
warning: Member S0BUF (macro definition) of file sioirq.c is not documented.
C:/Users/Public/projects_local/hemmerling/hemmerling_pwendean_keil/src/sioirq.c:38: 
warning: Member RI0 (macro definition) of file sioirq.c is not documented.

...

finalizing index lists...
writing tag file...
Combining RTF output...
lookup cache used 44/65536 hits=71 misses=44
finished...
irq.c is not documented.
C:/Users/Public/projects_local/hemmerling/hemmerling_pwendean_keil/src/sioirq.c:50: 
warning: Member oend (variable) of file sioirq.c is not documented.
...
*** Doxygen has finished
************************************
-- 
http://www.hemmerling.com
SCADA Expertness - Quality Intensification for IT + Automation
Member of Texas Instruments Expert Advisory Panel
CeBIT Competence Store Partner

[Doxygen-develop] Cannot work with salt of plantuml

[Zheng, B. <zhe...@gm...>]

Hi All,

I am using latest version of doxygen 1.8.9.1 and plantuml 8071. But doxygen
cannot work with salt subproject.

Step to reproduce my problem:

1) Type an example for plantuml

\startuml
salt
{
  Just plain text
  [This is my button]
  ()  Unchecked radio
  (X) Checked radio
  []  Unchecked box
  [X] Checked box
  "Enter text here   "
  ^This is a droplist^
}
\enduml


2) Run doxygen
I got an error in the html output:

salt: forbidden line salt

3) The generated .pu file is


@startuml salt { Just plain text [This is my button] () Unchecked radio (X)
Checked radio [] Unchecked box [X] Checked box "Enter text here " ^This is
a droplist^ } @enduml

PlantUML.jar cannot generate png for this file.

4) After I remove the new line after @startuml. PlantUML.jar can generate
png.

I can confirm doxygen will generate a new line after @staruml for every
plantuml code. But PlantUML require no new line for salt subproject.

Is it possible to fix it?

Best regards,
Bangyou

[Doxygen-develop] Dual-Boot Mode on my Laptop

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

Hello everyone,

Now that my laptop is old enough, I have decided to make it dual boot 
Windows and Linux (Fedora 21).  Everything worked right out of the box, 
including my wi-fi connection.  I have not tried my external blu-ray 
drive (though my laptop has an internal DVD drive), but everything else 
works.

After installing development packages through yum, I was able to get 
doxygen's command line interface to compile.  I still have yet to figure 
out how to get the GUI to work, but the GUI is low-priority to me as I 
know how to edit files manually using 'vim'.  After being away from 
Linux for several years, I am slowly getting used to using Fedora.

I am back in Windows currently, as that is where most of the apps I use 
work with.  But at least now, I have a much better way once again to 
verify bugs in Doxygen, especially crashers.  I have Doxygen compiled in 
debug mode for debugging crashers.

It is certainly about time that I got (though the old way) a linux 
subsystem of some sort installed.

- Kevin McBride

[Doxygen-develop] [PATCH] typo in doxmlparser subdirectory path

[Stephane F. <fi...@us...>]

Hi,

There's a typo in the doxmlparser subdirectory path.

diff --git a/addon/doxmlparser/examples/metrics/metrics.pro.in
b/addon/doxmlparser/examples/metrics/metrics.pro.in
index 3b2354d..f26a291 100644
--- a/addon/doxmlparser/examples/metrics/metrics.pro.in
+++ b/addon/doxmlparser/examples/metrics/metrics.pro.in
@@ -11,7 +11,7 @@ win32-borland:LIBS          += doxmlparser.lib qtools.lib
shell32.lib
 win32-borland:TMAKE_LFLAGS  += -L..\..\..\..\lib
 win32:TMAKE_CXXFLAGS        += -DQT_NODLL
 DESTDIR                     = ../../../../bin
-OBJECTS_DIR                 = ../../../../objects/doxmlparer/metrics
+OBJECTS_DIR                 = ../../../../objects/doxmlparser/metrics
 TARGET                      = metrics
 DEPENDPATH                  = ../../include
 INCLUDEPATH                += ../../../../qtools ../../include

Best Regards
-- 
Stephane

Re: [Doxygen-develop] PATCH limit warnings from doxygen

[<Pau...@am...>]

Dimitri

I hope you don't mind but I'm resending this to the develop list, this time with a smaller zip file as the previous one  bounced the email from the list and I am unsure if the list received the message.

The larger config.xml I removed, but outline the change needed here

-------------------------------------------------------
</docs>
    </option>
    <option type='int' id='LIMIT_WARNINGS' minval='0' maxval='10000' defval='0'>
      <docs>
<![CDATA[
The \c LIMIT_WARNINGS tag can be used to stop doxygen when a maximum number of warnings has been seen.
<br>
\b Tip: Turn warnings on while writing the documentation.
]]>
-------------------------------------------------------

Paul

From: Paul Hoad
Sent: 03 December 2014 12:57
To: 'dox...@li...'; 'di...@st...'
Subject: PATCH limit warnings from doxygen

Dimitri

I recently posted a question on StackOverFlow regarding being able to stop doxygen after it had seen a certain number of warnings, somewhat akin to the -ferror-limit=N option that certain compilers have.

http://stackoverflow.com/questions/27174031/possible-to-stop-doxygen-after-n-warnings

I have a large code base, mostly un-doxygen'd, I have a nightly build that runs doxygen but its produces thousands of warnings. I know getting full coverage is going to require a gradual continuous improvement approach which leads to a mindset change of the individual teams of developers.

So to tackle this I have added doxygen running on the current source subdirectory as "PreBuild Event" in Visual Studio project files, I don't want to use the temporary documentation it generates (that will come from the full tree nightly build), but I want to see the warnings, I format the warnings with

WARN_FORMAT            = "$file($line): $text"

Which this means that while the code is compiling, this allows the developer to go back in and double click the warnings in the output window and be taken to the location to fix those doxygen warnings (as they would any other warning), the problem is that for many of the directories the number of warnings is huge (which are too daunting to fix in one go)

I don't want to do a full Doxygen scan everytime (which is also why I only do it on the sub directory) because that will take too long and I don't want all the warnings or the developer will simply treat it a noise, I just want them to see a few and then stop.

My idea is to be able to tell doxygen to document locally only a certain number of warnings and then stop, this means that every build the developer will see a few more warnings (but only a couple 5-10) and be driven to fix those, over time the code will become documented and the developers will learn to document as they go, also any new code (especially in previously doxygen clean areas) will immediately become a warning. Think of it as "Continuous Incremental Documentation"

Given that I don't think this is possible currently, I took it upon myself to try and learn how to do it, I am very new to the doxygen source code, so I apologize in advance if I did it in the wrong place.

So the change to the doxygen source to implement something like this turned out to be fairly simple, with only having to add a new LIMIT_WARNINGS option to the config file, so I thought I would share the code change, feel free to use or discard as you see fit.

So I've not contributed before, so I'm not 100% clear of the etiquette or who to send any diffs to, so I've included the changed files and the diff from the tip of the git tree, if I should submit this another way, bug number etc.. let me know.

Paul

P.S. I couldn't find any requests like this in the bug tracker database.

[Doxygen-develop] New snapshot of Moritz 2.0.2 to generate nassi shneiderman and UML like activity together with some tutorials is available

[Eckard K. <eck...@t-...>]

Hello Everybody.

I wish you a happy new year.

Since some years I'm providing  Moritz a tool to generate source 
diagrams. First Moritz started with html-based nassi shneiderman 
diagrams and since  last year dot-based UML like activity diagrams are 
available also.

Currently I'm working on a possibility to create mscgen-based message 
sequence charts. Even this feature is not available until now for you, I 
have posted today a new snapshot for windows and linux. For other 
operation-systems the source-code is provided and the both binaries 
abc2xml and xml2abc should be usable with the linux distribution then.

Please take a look at:

https://sourceforge.net/projects/moritz/files/Moritz_2.x/DevelopmentFor_2_1_0/Snapshot_2_0_2/ 
<https://sourceforge.net/projects/moritz/files/Moritz_2.x/DevelopmentFor_2_1_0/Snapshot_2_0_2>

Here you will find a windows-distribution and one for linux (build with 
Ubuntu 14.04 for a 32bit system). Furthermore a the sources for the two 
binaries abc2xml and xml2abc.

New is a sub folder in this snapshot with some tutorials:
1. An introduction that explains a basic source example and the set up 
of the used tools.
2. A nassi shneiderman diagram example that shows how to create them and 
hoe to use them with doxygen.
3. A UML like activity diagram example that shows how to create them and 
hoe to use them with doxygen.

It would be kind if you would find the time to test it and please post a 
comment in the forum from Moritz.

Best regards,
Eckard Klotz.

Re: [Doxygen-develop] configure fails on Solaris

[Dagobert M. <da...@op...>]

Hi Dimitri,

> Am 29.11.2014 um 14:44 schrieb Dimitri van Heesch <do...@gm...>:
>> On 28 Nov 2014, at 12:16 , Dagobert Michelsen <da...@op...> wrote:
>> 
>> Hi Dimitri,
>> 
>> I noticed the current „configure“ of doxygen is broken on my Solaris continuous integration:
>>> 
>>> Autodetected platform solaris-g++... 
>>> Checking for GNU make tool... using /opt/csw/bin/gmake
>>> Checking for GNU install tool... using /usr/bin/install
>>> Checking for dot (part of GraphViz)... using /opt/csw/bin/dot
>>> 
>>> ./configure: syntax error at line 558: `libclang_hdr_dir=$' unexpected
>>> 
>>> program finished with exit code 2
>>> elapsedTime=0.264766
>> 
>> Can you please have a look?
> 
> I think a bash specific construct has crept in. Can you check if changing lines 558 and 559 by
> 
>    libclang_hdr_dir=`llvm-config --includedir`
>    libclang_lib_dir=`llvm-config --libdir`
> 
> helps?

Yes, that looks much better. You can check the doxygen build status on Solaris at
  https://buildfarm.opencsw.org/buildbot/waterfall?builder=doxygen-solaris10-i386&builder=doxygen-solaris10-sparc&reload=none
If you want I can set up email notification when something breaks.


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

Re: [Doxygen-develop] configure fails on Solaris

[Michael S. <ms...@re...>]

On 29.11.2014 14:44, Dimitri van Heesch wrote:
> Hi Dagobert,
> 
>> On 28 Nov 2014, at 12:16 , Dagobert Michelsen <da...@op...> wrote:
>>
>> Hi Dimitri,
>>
>> I noticed the current „configure“ of doxygen is broken on my Solaris continuous integration:
>>>
>>> ./configure: syntax error at line 558: `libclang_hdr_dir=$' unexpected
>>>
>>> program finished with exit code 2
> 
> I think a bash specific construct has crept in. Can you check if changing lines 558 and 559 by
> 
>     libclang_hdr_dir=`llvm-config --includedir`
>     libclang_lib_dir=`llvm-config --libdir`
> 
> helps?

actually command substitution with $(...) is not a bashism but perfectly
standard:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03

it's just that /bin/sh on Solaris (at least in Solaris 10) is so lame
that it doesn't implement it, only the inferior backtick `syntax` that
won't nest.

Re: [Doxygen-develop] configure fails on Solaris

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

Hi Dagobert,

> On 28 Nov 2014, at 12:16 , Dagobert Michelsen <da...@op...> wrote:
> 
> Hi Dimitri,
> 
> I noticed the current „configure“ of doxygen is broken on my Solaris continuous integration:
>> 
>> Autodetected platform solaris-g++... 
>> Checking for GNU make tool... using /opt/csw/bin/gmake
>> Checking for GNU install tool... using /usr/bin/install
>> Checking for dot (part of GraphViz)... using /opt/csw/bin/dot
>> 
>> ./configure: syntax error at line 558: `libclang_hdr_dir=$' unexpected
>> 
>> program finished with exit code 2
>> elapsedTime=0.264766
> 
> Can you please have a look?


I think a bash specific construct has crept in. Can you check if changing lines 558 and 559 by

    libclang_hdr_dir=`llvm-config --includedir`
    libclang_lib_dir=`llvm-config --libdir`

helps?

Regards,
  Dimitri

[Doxygen-develop] configure fails on Solaris

[Dagobert M. <da...@op...>]

Hi Dimitri,

I noticed the current „configure“ of doxygen is broken on my Solaris continuous integration:

> ./configure
> in dir /export/home/buildbot/slave/doxygen-solaris10-i386/build (timeout 1200 secs)
> watching logfiles {}
> argv: ['./configure']
> environment:
>  CC=/opt/solarisstudio12.3/bin/cc
>  CXX=/opt/solarisstudio12.3/bin/CC
>  HOME=/export/home/buildbot
>  LDFLAGS=-R/opt/csw/lib
>  LOGNAME=buildbot
>  MAIL=/var/mail//buildbot
>  MANPATH=/usr/share/man:/opt/csw/share/man
>  PATH=/opt/csw/gnu:/usr/bin:/usr/ccs/bin:/opt/csw/bin
>  PWD=/export/home/buildbot/slave/doxygen-solaris10-i386/build
>  SHELL=/opt/csw/bin/bash
>  SHLVL=1
>  SSH_CLIENT=192.168.1.8 51910 22
>  SSH_CONNECTION=192.168.1.8 51910 192.168.1.33 22
>  TZ=Europe/Berlin
>  USER=buildbot
>  _=/opt/csw/bin/buildslave
> using PTY: False
> 
>  Autodetected platform solaris-g++... 
>  Checking for GNU make tool... using /opt/csw/bin/gmake
>  Checking for GNU install tool... using /usr/bin/install
>  Checking for dot (part of GraphViz)... using /opt/csw/bin/dot
> 
> ./configure: syntax error at line 558: `libclang_hdr_dir=$' unexpected
> 
> program finished with exit code 2
> elapsedTime=0.264766

Can you please have a look?

You can also check the status at
 https://buildfarm.opencsw.org/buildbot/waterfall?builder=doxygen-solaris10-i386&builder=doxygen-solaris10-sparc&reload=none


Best regards

 — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896


-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

Re: [Doxygen-develop] segfault with cyclic subgroups

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

Hi Helmut,

> On 01 Nov 2014, at 18:02 , Helmut Grohne <he...@su...> wrote:
> 
> Dear Doxygen developers,
> 
> I am faced with a segmentation fault of Doxygen 1.8.8 (as used by Debian
> unstable on amd64) when trying to process the following (invalid?)
> header:
> 
> | /**
> |  * @addtogroup foo1 foo2
> |  * @{
> |  * @addtogroup foo4 foo5
> |  * @{
> |  * @defgroup foo1 foo3
> |  * @}
> |  * @}
> |  */
> 
> While this example looks artificial, it was processed by earlier
> versions of Doxygen and the Enlightenment libraries reproduce the same
> segmentation fault (see https://bugs.debian.org/762272).
> 
> What happens is that stack space is exhausted in a recursion of
> recursivelyAddGroupListToTitle. Turns out the recursion alternates
> between group foo1 and foo4. Conceptually, I have no clue what cyclic
> subgroup membership is supposed to mean. One way to look at this problem
> is to argue that Doxygen fails to refuse processing cyclic subgroups.
> Alternatively the depth of the recursion can be limited.
> 
> I am proposing the attached patch (suitable to "git am") to make Doxygen
> error out when faced with cyclic subgroups. Is this patch reasonable for
> inclusion upstream and does it fully fix the problem?

It think it will still fail on larger cycles, e.g.: a->b->c->a

> 
> I would like to add some minimal fix to the Debian package as Debian
> jessie is almost frozen (i.e. a new upstream release of Doxygen cannot
> be added to Debian atm).
> 

I've pushed a variation of your patch:
https://github.com/doxygen/doxygen/commit/c83db38ea83499be19d9ff242bfa22ae534ee80c
Let me know if it solves the problem.

Regards,
  Dimitri

[Doxygen-develop] segfault with cyclic subgroups

[Helmut G. <he...@su...>]

Dear Doxygen developers,

I am faced with a segmentation fault of Doxygen 1.8.8 (as used by Debian
unstable on amd64) when trying to process the following (invalid?)
header:

| /**
|  * @addtogroup foo1 foo2
|  * @{
|  * @addtogroup foo4 foo5
|  * @{
|  * @defgroup foo1 foo3
|  * @}
|  * @}
|  */

While this example looks artificial, it was processed by earlier
versions of Doxygen and the Enlightenment libraries reproduce the same
segmentation fault (see https://bugs.debian.org/762272).

What happens is that stack space is exhausted in a recursion of
recursivelyAddGroupListToTitle. Turns out the recursion alternates
between group foo1 and foo4. Conceptually, I have no clue what cyclic
subgroup membership is supposed to mean. One way to look at this problem
is to argue that Doxygen fails to refuse processing cyclic subgroups.
Alternatively the depth of the recursion can be limited.

I am proposing the attached patch (suitable to "git am") to make Doxygen
error out when faced with cyclic subgroups. Is this patch reasonable for
inclusion upstream and does it fully fix the problem?

I would like to add some minimal fix to the Debian package as Debian
jessie is almost frozen (i.e. a new upstream release of Doxygen cannot
be added to Debian atm).

Thanks for considering

Helmut

Re: [Doxygen-develop] Superscript does not work anymore since 1.8.7

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

Andreas,

I did a quick test with a number of versions (on windows with a .c file):
- 1.8.6: warning: Unsupported symbol ² found
  x^2 is not a supported text, it is supported however inside formulas.rest
shown
- 1.8.7 and 1.8.8 everything is shown properly

So I don't see what is not working, if the problem is present please make a
small example including the used Doxyfile.

Albert

On Thu, Oct 23, 2014 at 1:36 PM, Andreas Tscharner <an...@vi...> wrote:

> The subject says all: Superscript does not work any longer since at
> least 1.8.7.
>
> It does not matter if I use
> x^2
> x<SUP>2</SUP>
> &sup2;
>
> They all result in "x^2" in the HTML output.
>
> Best regards
>         Andreas
> --
>        ("`-''-/").___..--''"`-._
>         `o_ o  )   `-.  (     ).`-.__.`)
>         (_Y_.)'  ._   )  `._ `. ``-..-'
>       _..`--'_..-_/  /--'_.' .'
>      (il).-''  (li).'  ((!.-'
>
> Andreas Tscharner   an...@vi...   ICQ-No. 14356454
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>