[CMake] Fortran-C mixed code (possible solution)

Arjen Markus arjen.markus at wldelft.nl
Mon Jan 22 02:37:41 EST 2007


Radu Serban wrote:

>
> Hi Arjen,
>
> That's not what I want for several reasons:
> 1) I really think this is something that the build system should take 
> care of. I intend to provide cmake only as an alternative to autotools 
> and determining the Fortran name mangling scheme with the later is no 
> problem.

I agree that ideally the build system should take responsibility.

> 2) A typical Fortran-C interface library (and we provide such 
> libraries for 3 different solvers) contains around 30 different 
> functions which would then require 180 wrappers (for all combinations 
> lower/upper case and none/one/two underscores)! A nightmare of 
> (unnecessary) code duplication.

Not necessarily:
You can put the actual wrapper functions in a separate file and include 
it several
times, like this:

#define suba SUBA
#include "wrappers.h"
#define suba SUBA_
#include "wrappers.h"
#define suba SUBA__
#include "wrappers.h"
...

Maybe not the most elegant way to solve it, but somewhere you need
the six combinations of case/appended underscores.

> 3) We distribute our solvers open source and we'd like to keep the 
> sources as clean and readable as possible.

The above seems relatively clean to me, if not very elegant.

>
> In any case, I think I have a solution. I seems to work, but then I've 
> only tried it on my Linux box. It's probably not the cleanest 
> implementation (I've only started using cmake very recently). I copied 
> the relevant portion of my CMakeLists.txt below. I'd appreciate any 
> comments and suggestions, both on whether it can be 
> simplified/cleaned-up and also on whether it's portable.
>
If this is indeed a useable solution, then there is no need for mine of 
course. Perhaps
this functionality should be included in the various Fortran modules - 
you are certainly
not the only one facing this problem.

Regards,

Arjen




More information about the CMake mailing list