Utility to generate a .hh file from a .mod file?

[David Ham]

On 02/11/10 21:14, Kent Budge wrote:
> I could use one.
>
> Let me elaborate.
>
> I'm currently working on a C++ wrapper for a large collection of stellar
> astrophysics code modules, MESA (mesa.sourceforge.net), written in
> Fortran-95 and routinely built with ifort 11.0 and gfortran 4.4.4 or
> later. The Fortran developers did a bang-up job, deliberately writing
> their code in such a way that developing a C++ wrapper would be easy as
> possible.
>
> However, it's still going to be a daunting task to keep the C++ wrapper
> and the wrapped Fortran-95 synchronized. It would be extremely useful
> for me to have a utility to read a .mod file and convert it to a C++ .hh
> file. With the right platform-dependent macros, the resulting .hh should
> be fairly portable if the original Fortran-95 interface stayed away from
> shaped arrays and the like, as is the case with MESA.
>
> I can imagine a utility, let us call it mod2hh, that takes file.mod as
> its argument and, by default, generates file.mod.hh containing C++
> prototypes for the functions and variables in file.mod. A macro would
> string together the function name and module name in whatever manner is
> appropriate for the platform -- for example, a subroutine foo taking no
> arguments and living in module bar would be represented in file.mod.hh
> as
>
> 	extern "C" {
> 		void F95(foo, bar)();
> 	}
>
> where, for a Linux system with gcc as the default compiler suite, the
> macro F95(name, mod) would expand as __mod_MOD_name as needed for
> linking. Users of the header would likewise use the F95 macro in their
> function calls
>
> 	#include "file.mod.hh"
>
> 	int main()
> 	{
> 		F95(foo, bar();
> 	}			

Can I suggest that this approach is obsoleted by the C interoperability 
features of Fortran2003 which have been in gfortran for a while (and are 
also in Intel since I notice you use that).

The C interoperability features allow Fortran entities to be declared in 
ways which cause the compiler to generate names without __mod__, 
trailing underscores or other compiler-specific features. Clearly this 
does not solve all of your problems as it still doesn't generate header 
files automatically but it does mean that if you wrote such a tool based 
on elements of, for example, gfortran, the header files so generated 
would still be valid were the program compiled with a different compiler.

See, for example, chapter 14 of Metcalf, Reid and Cohen.

>
> By default, mod2hh would not attempt to generate signatures for non-flat
> functions and subroutines, but would issue a warning instead. This could
> be overridden with a -q flag (don't issue warnings) or a -f flag (write
> a prototype that exposes the non-portable hidden arguments). I'm not
> terribly interested in the latter at the moment, though, and doubt many
> others would be -- the right thing is to write an internal flat Fortran
> wrapper and hook the C++ to that instead.
>
> Now, it strikes me that I'm not the only one who would find this very
> useful. So I'm curious if you are aware of anyone already working on
> this?
>
> I've poked around in module.c in the gfortran source, thinking I could
> easily adapt it to do what I want. However, it looks like this is rather
> tightly integrated to the rest of the gfortran compiler. I could hack a
> version that does what I want, but then the problem is to keep it
> synchronized with new versions of gfortran. Any suggestions?
>
> Rather than a separate mod2hh utility, it might be nice to have a
> --mod-to-hh flag on the gfortran compiler itself, but perhaps that's
> just too ugly to contemplate.
>
> --Kent G. Budge
>
>


-- 
Dr David Ham
Applied Modelling and Computation Group,
Department of Earth Science and Engineering,
Imperial College London,

http://www.imperial.ac.uk/people/david.ham