I looked into this problem and it does not seem easy to solve. NamespaceDef entities are not MemberDef entities and it looks like many things has to be changes to solve this problem.

The easiest way (requires almost no changes) is to make Function entities from 'programs' and leave 'modules' as Namespace entities. I've tried it out and it works, the only visible consequence is that they are not listed under modules list anymore. Actually, it may be the correct behaviour, because they have code to run and their local variables are not exposed to others.

I do not know how and where global (not module) variables are declared. This may be important, because once we make Functions out of 'programs' we may get into troubles with their visibility.

I found the same problem. The solution was to use a "C like" style with a main subroutine :

program test
call main()
contains
   subroutine main()
      implicit none
      call a
   end subroutine main
end program test

subroutine a
print *, "Hello world"
end subroutine a

Just a workaround with some lines more, but then you have a complete call graph

Created attachment 137091 [details] [review]
Proposed patch to treat PROGRAM statements in Fortran as subroutines and functions

This patch *seems* to fix the fact that the program statement in Fortran is treated by doxygen as a module rather than a subroutine or function.  However, I don't know doxygen very well, so I may have missed something.

(Apparently, I lost the body of my message while uploading the attachment in the previous post.  Here it is.)

(Apparently, I lost the body of my message while uploading the attachment in the previous post.  Here it is.)


(In reply to comment #1)
> The easiest way (requires almost no changes) is to make Function entities from
> 'programs' and leave 'modules' as Namespace entities. I've tried it out and it
> works, the only visible consequence is that they are not listed under modules
> list anymore. Actually, it may be the correct behaviour, because they have code
> to run and their local variables are not exposed to others.

I think this is the correct behaviour.  The Fortran 
program name
  ...
end program name

defines the main routine of a program, just like the 

void main() {
  ...
}

statement in C.  Hence there can only be one such routine in a program, and it 
cannot be called by other routines.  Other than that, the contents of a program
are the same as those of a subroutine or a function.  Hence, a program should
NOT be listed under modules (as it is now) and should be treated as a subroutine
or function, so that it is included in the call graph (which it isn't at the 
moment, which, it being the main routine, has quite an impact on the call graph.


> I do not know how and where global (not module) variables are declared. This
> may be important, because once we make Functions out of 'programs' we may get
> into troubles with their visibility.

I have been programming in Fortran for about eight years now, and I have never 
used a global variable (as they exist in C).  I have tried to look up 'global
variables' in my reference books and google for them, but can't find anything 
else than 'use modules' (or common blocks for Fortran 77).

It would be really useful if this change were made (treat program as subroutine).  
I attach a patch for doxygen 1.5.8 that seems to do the trick, though I'm not 
100% confident that I didn't miss anything.  If someone who knows doxygen better
could check, that would be great, I'd like to push the patch into the Gentoo 
package tree until it's resolved here.

Created attachment 137423 [details] [review]
Original (alternative) patch to treat PROGRAM statements in Fortran as subroutines and functions

This is one mentioned in comment 1. Need to figure out if this fix is better. In the while solving some serious caller/callee issues (local variables are ignored).

Thanks Oleg, I'll include your patch in the next subversion update.

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.6.0. Please verify if this is indeed the case and reopen the
bug if you think it is not fixed (include any additional information that you
think can be relevant).

For me this bug is still present in the version 1.8.9.

Can some one test it?

Doxygen 1.8.9 seems to be fine for me.  I just reran it for rochePlot and the program is recognised as such, and shows up in Caller and Callee graphs: http://tinyurl.com/oowsw99

I tested it with my original example... and with the attached Doxyfle and works!


Regards,
Alin

Created attachment 305493 [details]
doxyfile used