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-18.104.22.168-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.
+ <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
<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);
- current->section = Entry::NAMESPACE_SEC;
+ if (Config_getBool("FORTRAN_MODULES_AS_CLASSES"))
+ current->section = Entry::CLASS_SEC;
+ current->section = Entry::NAMESPACE_SEC;
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,
> 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
>>> 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:
>>> 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 22.214.171.124 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
Home page: http://www.webalice.it/o.drofa/davide/
Address: ARPA-SIM, Viale Silvani 6, 40122 Bologna, Italy