Philipp Eppelt | 21 Jun 10:47 2016

copy only used params with copydoc

Hello,

I am looking for a way to extend copydoc to only copy descriptions for
parameter, which are present in the function where the documentation is
copied to. So instead of a "argument .. of command  <at> param is not found
in the argument list of .." warning I'd like to remove this specific
param documentation.

Alternatively, I would be happy with an option to remove a param
statement from the documentation. Something along the line:

\copydoc Foo::bar(bar1, bar2)
\rmparam bar2

I tried hijacking parseCopyDoc() in docparser.cpp, but this doesn't look
promising.
At the end it should be something like this:

while(..)
{
tk = copyDocString.nextToken();
if( !checkArgumentName(tk, tk.isParam()) )
    //check argument name was modified to return false in case of the
above error.
    toBeRemovedTokens.add(tk);
}
// remove tokens from copyDocString

Do you have any hints, how to best achieve this? Or could you point me
to a good place in the code for this?
(Continue reading)

Stefan Dröge | 30 May 12:32 2016
Picon

Bug(?) VHDL UML class diagrams contain libraries and use clauses as members

Hi everyone,
I am using doxygen to document my VHDL code, and I activated the "UML_LOOK = YES" option, to generate UML style diagrams.
I noticed, that the Libraries (like "ieee") and Use Clauses (like std_logic_1164) are listed as public members in the diagrams (see attached image, or github project, below). In my opinion they should be treated like "#include" statements in C.

I have provided an example project here: https://github.com/StefanD986/doxygen_vhdl_bug_example

You don't need any vhdl compiler to test it. Just clone and build the doxygen documentation in doc/.

-- Stefan
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Doxygen-develop mailing list
Doxygen-develop <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-develop
Li.Bin(李斌 | 27 Apr 10:04 2016

Adding a new language support to Doxygen

Hi all,

We implement a new language named CAR (Component Assembly Runtime, 
http://elastos.org/), which has a similar grammar with the traditional IDL.

Is there a tutorial or suggestion to implement the new language support?

Thanks a lot.

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Petr Parik | 7 Jan 15:53 2016
Picon

Minor bugs report & question

Hello developers,

a fix to the following minor bugs would be most appreciated:

#1: If a module IS NOT documented its members still appear in the "File 
Reference" page.

#2: If a module IS documented but the file itself is not the module 
still appears in the "Modules List" page and "Module Reference" page.

I am including minimum working examples (Fortran).

Best regards,

Petr Parik

P.S. If a module is documented but some of its members are not, should 
those undocumented members be included in the "Module Reference" page 
when EXTRACT_ALL = NO ?

INPUT                = test1.f
OUTPUT_DIRECTORY     = test1
OPTIMIZE_FOR_FORTRAN = YES
GENERATE_LATEX       = NO
C> \file
C> The modules are not documented so their members should not be included in the documentation.
      MODULE MOD_VISIBLE
      IMPLICIT NONE

      INTEGER VAR_PUB
      INTEGER VAR_PRIV

      PRIVATE VAR_PRIV,SUB_PRIV

      CONTAINS

      SUBROUTINE SUB_PUB
      END SUBROUTINE

      SUBROUTINE SUB_PRIV
      END SUBROUTINE

      END
      MODULE MOD_HIDDEN
      IMPLICIT NONE

      INTEGER VAR_PUB
      INTEGER VAR_PRIV

      PRIVATE VAR_PRIV,SUB_PRIV

      CONTAINS

      SUBROUTINE SUB_PUB
      END SUBROUTINE

      SUBROUTINE SUB_PRIV
      END SUBROUTINE

      END
INPUT                = test2.f
OUTPUT_DIRECTORY     = test2
OPTIMIZE_FOR_FORTRAN = YES
GENERATE_LATEX       = NO
C>  The file is not documented so this module should not be included in the documentation.
      MODULE VISIBLE
      IMPLICIT NONE

      INTEGER VAR_PUB
      INTEGER VAR_PRIV

      PRIVATE VAR_PRIV,SUB_PRIV

      CONTAINS

      SUBROUTINE SUB_PUB
      END SUBROUTINE

      SUBROUTINE SUB_PRIV
      END SUBROUTINE

      END
      MODULE HIDDEN
      IMPLICIT NONE

      INTEGER VAR_PUB
      INTEGER VAR_PRIV

      PRIVATE VAR_PRIV,SUB_PRIV

      CONTAINS

      SUBROUTINE SUB_PUB
      END SUBROUTINE

      SUBROUTINE SUB_PRIV
      END SUBROUTINE

      END
------------------------------------------------------------------------------
_______________________________________________
Doxygen-develop mailing list
Doxygen-develop <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-develop
Gautier | 3 Dec 21:34 2015
Picon
Gravatar

[PATCH] Add TREAT_WARNINGS_AS_ERROR option

Hi list;

As stated on Github[1], I would like to add an option behaving similarly 
to compilers' -Werror option: any warning generated during Doxygen 
execution will abort it immediately.

This option is, in my opinion, valuable to keep documentation up-to-date 
with code changes, specially when multiple people are working altogether.
I will not blame anyone to not think all consequence of a code change, 
but scripts can help him/her from breaking anything:

* strict compiler options (-Werror, -Wall, etc.) prevents at least some 
quick&dirty code and obvious bugs. Compilers will warn beginners about 
code which will not work (out of bounds errors, etc.), but most of the 
time it's simply about a typo / useless dead code.
* Git hook preventing users from pushing invalid commits [2]. We are 
intensively using git submodules for instance - it's quite easy to push 
an invalid submodule reference to git:
     * if you forgot to run "git submodule update --recursive" after 
pulling remote changes following by a "git commit -a", leading to 
unwilling submodule downgrading.
     * if you're referencing a new submodule revision... which you 
forgot to push first!
* To have better code consistency, following a single code style using 
clang-format[3], similarly to what systemd does[4].

I think that all of us already encountered one or several of these 
issues at least once ;-). Having tools checking these errors 
automatically allow me not to worry about it anymore.
Our documentation contains nowadays many errors simply because Doxygen 
let us do that and we did not look at """inoffensive""" warnings, since 
they are not preventing us from continuing - they are lost in the 
verbosity of build logs.

I am the only one which would like such an option, and if so: how do you 
keep your documentation up-to-date?

Cheers,

Gautier

[1] https://github.com/doxygen/doxygen/pull/412
[2] https://gist.github.com/bagage/bdca3d4b66d43db7a5e3
[3] http://clang.llvm.org/docs/ClangFormat.html
[4] https://github.com/systemd/systemd/blob/master/autogen.sh

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
c.buhtz | 18 Nov 21:49 2015
Picon

(some) inheritance are ignored if __init__.py is empty

Related to <https://bugzilla.gnome.org/show_bug.cgi?id=757509>

I try to use Doxygen with Python-code. But I have some problems with
the inheritance and how this is displayed in the generated docs.

I generated documentation with Doxygen (in default configuration) for
the code below. But the problem is that a.ABase in the inheritance tree
of B-docu is not linkable/clickable. Even when you look at the tree for
a.ABase the class B is not shown.

This depends on the existence of the __init__.py file. I don't know
why. When I delete the __init__.py everything is fine.

Can someone check that if it is reproducable?
--

-- 
GnuPGP-Key ID 0751A8EC

------------------------------------------------------------------------------
Picon

[PATCH] Decrease CMake version

Signed-off-by: Brilliantov Kirill Vladimirovich <brilliantov <at> byterg.ru>
---
 CMakeLists.txt     | 2 +-
 src/CMakeLists.txt | 8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3695093..0b5308c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
 <at>  <at>  -11,7 +11,7  <at>  <at> 
 # Documents produced by Doxygen are derivative works derived from the
 # input used in their production; they are not affected by this license.

-cmake_minimum_required(VERSION 2.8.12)
+cmake_minimum_required(VERSION 2.8.11)
 project(doxygen)

 option(build_wizard    "Build the GUI frontend for doxygen." OFF)
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 155bf77..4532b97 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
 <at>  <at>  -17,8 +17,8  <at>  <at>  file(GLOB LANGUAGE_FILES "${CMAKE_SOURCE_DIR}/src/translator_??.h")
 add_definitions(-DYY_BUF_SIZE=262144 -DYY_READ_BUF_SIZE=262144)

 # generate settings.h
-file(GENERATE OUTPUT ${GENERATED_SRC}/settings.h
-CONTENT "#ifndef SETTINGS_H
+file(WRITE ${GENERATED_SRC}/settings.h
+"#ifndef SETTINGS_H
 #define SETTINGS_H
 #define USE_SQLITE3 ${sqlite3}
 #define USE_LIBCLANG ${clang}
 <at>  <at>  -31,8 +31,8  <at>  <at>  set_source_files_properties(${GENERATED_SRC}/settings.h PROPERTIES GENERATED 1)

 
 # generate version.cpp
-file(GENERATE OUTPUT ${GENERATED_SRC}/version.cpp
-    CONTENT "char versionString[]=\"${VERSION}\";"
+file(WRITE ${GENERATED_SRC}/version.cpp
+    "char versionString[]=\"${VERSION}\";"
 )
 set_source_files_properties(${GENERATED_SRC}/version.cpp PROPERTIES GENERATED 1)

--

-- 
2.1.4

------------------------------------------------------------------------------
Kevin McBride | 2 Aug 22:31 2015
Picon

Getting Debug Info Built in the Sources

Hello,

As a tip for developers new to CMake, I use the following command to 
build doxygen and the doxywizard with debug symbols that gdb can use:

"cmake -G "Unix Makefiles" -Dbuild_wizard=on -DCMAKE_BUILD_TYPE=Debug 
$OLDPWD"

This is a necessity on Fedora to get stack traces from crashers.

I think this information should be put in the BUILD.txt file in GIT.

- Kevin McBride

------------------------------------------------------------------------------
Phyks | 18 Jun 12:44 2015

Issue with # in inline code in markdown

Hi,

I have an issue with preprocessor directives in inline code in Markdown 
readme included in Doxygen doc. When compiling the file, I get

```
README.md:175: warning: explicit link request to 'if' could not be 
resolved
```

Due to the line in the README.

```
* Code should **never** be commented out. To temporarily comment some 
code, use `#if 0` preprocessor directive.
```

It compiles fine, but there is still a warning during compilation.

Note also that the warning message refers to line 175 although my 
README.md file has only 169 lines (and the faulty one is the last one).

Thanks!
--

-- 
Phyks

------------------------------------------------------------------------------
Phyks | 18 Jun 12:48 2015

Warning: Unexpected html tag <img> found within <a href=...> context

Hi,

I've just encountered this issue in a Markdown file: 
http://sourceforge.net/p/doxygen/mailman/message/12235967/.

However, according to the thread, I understand it was fixed in 1.2.6 and 
I am using 1.8.9.1.

Thanks
--

-- 
Phyks

------------------------------------------------------------------------------
Alexander.Elgert | 27 May 20:12 2015

documenting bash function with dots and dashes inside

Hello,

 

I asked this question on the doxygen users list, but without any luck.

It would be nice if this little feature could be added to the doxygen code to parse bash functions correctly.

Besides of this little parser problem it works like a charm!

 

I found a little doxygen filter for bash functions:

 

http://www.cbica.upenn.edu/sbia/software/basis/apidoc/v1.0/doxyfilter-bash_8py_source.html

 

After a few changes, it works really fine for my sources (60_000 loc).

(Attached, plus Example file)

 

But there is a thing, which is really annoying, there are tons of bash-functions, which uses a dot or a minus in the function name (which is allowed in bash), for example:

 

function e.() {

      echo "hello"

}

 

function e-e() {

      echo "foo"

}

 

Is there a chance to add the dot and the minus for function names, so that doxygen is able to parse these names correctly?

It would be very helpful.

 

Thank you.

 

Best regards,

Alexander Elgert

 

Attachment (zbashrc2_test): application/octet-stream, 973 bytes
Attachment (doxyfilter-bash.py): application/octet-stream, 9 KiB
------------------------------------------------------------------------------
_______________________________________________
Doxygen-develop mailing list
Doxygen-develop <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Gmane