[CMake] C++ and FORTRAN

[Maik Beckmann]

Am Mittwoch 28 Mai 2008 15:03:46 schrieb Allen Barnett:
> Hi: I have a project which consists of a C++ main and a set of FORTRAN
> computational routines which I'm trying to build on windows XP. I'm
> using visual studio 2008 (VC9) and the Intel FORTRAN compiler (10.1) on
> IA32. I'm also using CMake 2.6 patch 0.
> If I generate NMake Makefiles, everything works correctly; both the C++
> main and the FORTRAN subroutines are correctly compiled and linked.

Sweet!

> However, if I generate a visual studio 2008 project and try to build it
> within the GUI, the FORTRAN object is not compiled. (I have to admit
> nearly complete ignorance about how visual studio works so this is very
> likely a case of operator error; but it looks like no compilation
> directives are created for the FORTRAN source file.)
> I attached some files which emulate my project. Any guidance would be
> greatly appreciated.

Intel brings its own Project types called "Visual Fortran".  So cmake must 
generate a solution file which contains a mix of Visual C++ and Visual 
Fortran Projects. 

The Visual Fortran support in cmake-2.6 has recently been added by Bill 
himself.  So its best he comments if this can be done and how important this 
is to him.

I use the the intel fortran compiler at work and do my coding via Visual C++ 
Makefile Projects.  This work fine for nmake, mingw32-make and cygwin-make.

However, Visual Fortran support might be of greater importance than I 
considered it yet.  Especially for those who start coding and don't familiar 
with make tools at all.  I'll put some time on it.

BE AWARE: Mixing two languages has some pitfalls you have to be aware of.  
Your code will most likely compile on all platforms and compilers, but 
linking plain object files into one piece is another issue.  Using the c++ 
linker might force you give cmake the name of the fortran runtime library.  
Using the fortran linker might force you to give cmake the right c++ runtime 
library to link in.  The cleanest solution is to put either one language code 
into its own dll/so and link to it this one from the other.  Given your 
platform has dynamic linking.  I don't know if this solution works for static 
libs as well, does anyone?


-- Maik