itaps-parallel Fortran name mangling issues

[Jason Kraftcheck]

Onkar Sahni wrote:
> I think my point is being missed, here is my last attempt... if in case of
> MOAB "AC_CONFIG_HEADERS is called to produce MBCN_FCDefs.h" why not one
> can produce "ITAPS_FCDefs.h" in a central place and one central
> iMesh_protos.h includes ITAPS_FCDefs.h that is generated during as an
> install/build process (all ITAPS header files can live in one location,
> for example, /usr/local/itaps/headers).
> 
> In summary, user/app. would do following basic steps:
> 
> * Download itaps-headers (say in /<path-itaps-headers>/)
> * Run configure to generate ITAPS_FCDefs.h in /<path-itaps-headers>/ (an
> app./user would do this step with platform and compiler combination of
> their choice)
> 

How is this any simpler then the user just configuring everything with the
same Fortran compiler.  Either way, they have to be careful to specify the
correct option (either a path to an external, configured header or a Fortran
compiler.)  However, if they only have to specify the Fortran compiler, then
they don't need to worry about downloading and configuring some additional
stuff.  Perhaps it would be to make all implementations default to no name
mangling unless the user explicitly requested it as there are fewer Fortran
users and the complexity is due to supporting Fortran.

But if we're going to ask that the user download some extra stuff, I still
think the best solution is to just not mangle names at all in the C API and
provide a separate Fortran wrapper on top of the C bindings.  Then if the
user wants Fortran bindings they can download, configure and build them.  If
they do not, everything works fine automatically.  Even better is that then
Fortran clients can include their own copy of the Fortran wrapper that is
configured the same as whatever Fortran compiler is being used to build the
app.  That way we also avoid problems with multiple Fortran compilers with
different mangling conventions.

Further, not using the same functions to implement both bindings allows us
to make the APIs more natural for the language (i.e. the error code as a
return value in C, not passing string lengths in C, etc.)

- jason