itaps-parallel Fortran name mangling issues

[Onkar Sahni]

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)

* Download any implementation/service (such as FMDB/MOAB/GRUMMP or iZoltan)
* Run configure and compile it (point to /<path-itaps-headers>/ to get
header files from central place)

* Write app. code like MHD solver
* Build it and link with appropriate libs. (ofcourse fortran name mangling
has to be consistent while compling app. code with ITAPS_FCDefs.h
generated by app.)

Is this not possible?

- Onkar

> On Wed, 2008-11-12 at 16:53 -0500, Onkar Sahni wrote:
>> > The FC_FUNC macro winds up getting defined by something; Autoconf's
>> configure script does some work to define it. Or, like Onkar suggests,
>> you can define some logic ahead of time to set whatever FC_FUNC does
>> using logic like so...
>> >
>> > #ifdef AIX
>> > #define FC_FUNC(lowFunc,UPfunc) _lowFunc
>> > #elif GFORTRAN
>> > #define FC_FUNC(lowFunc,UPfunc) UPfunc
>> > #elif ...
>> > ..
>> > .
>>
>>   So here is my question (basically what I was trying to ask in
>> tele-con)
>> which may or may not be possible:
>>
>>   Can "#define FC_FUNC............" be generated in a central place
>> during
>> the process to install and build itaps softwares (before building any
>
> I don't think it can because its definition depends on the name mangling
> properties of the fortran compiler being used at time of (configuration)
> compilation. Yes, the number of possible definitions for FC_FUNC is
> finite, but know which it should be set to for a given compiler (and
> what to use in the way of a detecting that) varies from compiler to
> compiler. The BEST you can achieve is to identify what FC_FUNC should be
> identified for common cases or cases that you know of so that it doesn't
> need to be re-computed with each configure/compile.
>
>> implementation/library or service). This would be an extra configure
>> step in say /usr/local/itaps/headers (central location where all headers
>> sit along with probably configure stuff) and this step would just
>> generate a new header file say "itaps_fc_func.h".
>
>
>> Say if one uses gfortran then the header file generated in "central"
>> place
>> (as an extra step using configure in "central" place) will contain
>> following lines and every service and implementation simply use it.
>>
>>   #ifndef _ITAPS_FC_FUNC_H_
>>   #define _ITAPS_FC_FUNC_H_
>>
>>   /* following line is for specific platform, compiler... combination */
>>   #define FC_FUNC(lowFunc,UPfunc) UPfunc
>>
>>   #endif
>>
>> - Onkar
>>
>> >
>> > The only issue I see with this approach is that you need to have
>> defined
>> ahead of time all the possible #ifdef #elif cases above and whenever you
>> go to a new machine, then you'll have to re-visit this logic. So, I like
>> the approach where Autconf's configure is used to set FC_FUNC.
>> >
>> > Finally, whatever FC_FUNC is set to, it MUST match the actual name
>> mangling used by whatever fortran compiler is being used to compile the
>> code. So, it is not just a matter of everyone agreeing on an
>> > implementation for FC_FUNC. FC_FUNC must also address whatever name
>> mangling is being used by a given fortran compiler on a given platform
>> when the code is getting compiled. For that reason, I think the best
>> approach is the Autoconf approach.
>> >
>> > Mark
>> >
>> >
>> > --
>> > Mark C. Miller, Lawrence Livermore National Laboratory
>> > email: mailto:miller86 at llnl.gov
>> > (M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
>> > (Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)
>> >
>> >
>>
>>
>>
>>
> --
> Mark C. Miller, Lawrence Livermore National Laboratory
> email: mailto:miller86 at llnl.gov
> (M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
> (Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)
>
>