[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