Tips on moving project from Compaq to Intel FORTRAN under VS2008?

[chris-sn]

I have a couple of legacy projects in FORTRAN, that currently compile and run using COMPAQ FORTRAN under VS2008. I have a budget to upgrade to Intel FORTRAN ;-) and have downloaded the evaluation version.

The old projects are mostly .FOR with a single C++ file which wraps the small number of external entry points. In VS2008, the FORTRAN compilation is handled by an explicit command line specified in configuration properties like this:

fl32 /c /nologo /MD /include:"C:\\Program Files\\Microsoft Visual Studio\\DF98\\IMSL\\INCLUDE" /W1 /I.. /I. /4Yd /4Ya /DOS_WINDOWS /Od /Fm /Zi -c /Fo$(IntDir)$(InputName).obj $(InputDir)$(InputName).for

I guess the bull-at-a-gate approach is to use the same approach and construct the modern Intel equivalent command line (ifort , I guess). It's a bit optimistic that someone has a simple conversion table for the compiler options but no harm in asking ..;-)

But I was wondering whether it might be more elegant to create a new FORTRAN project and import the existing files...which begs the question of whether I can include the C++ file in a FORTRAN project?

[I also have to deal with IMSL - due to cost it would be convenient if only one developer needed the IMSL licence with the other FORTRAN developers picking up his object files - but this is a separate issue, I think]

TIA, Chris

[Les_Neilson]

Chris
First you might start by reading this article explaining the migration path.

The part where it tellsyou to "Extract Compaq Visual Fortran Items" explains how, with mixed languages, you can make it so thattwo projects will be created within the one solution (one project for C++ and the other for Fortran) We did this some time back and it is quite painless.

Les

[chris-sn]

Thanks Les, certainly some useful stuff in there - I have a feeling the inter-language calling conventions are going to bite me, good to be forewarned!

I'm not sure itanswers the central point of my post though. Contrary to the article, it clearly *is* possible to mix FORTRAN and C++ within a visual studio project, although perhaps not very elegantly - see the original post - and Idon;t have a strong feeling onwhether to stay with that or not. On the recommended conversion route, the .dsw and .dsp files went some time ago when I switched to VS2008... The second part of the recommended conversion, the automatic extraction intoseparate FORTRAN and C++ projects, looks interesting though it refers to static libraries whereas I am trying to createa dynamic library...I guess I can change this afterwards?

Chris

[rase]

Automatic conversion or new project: I used the two approaches, and I recommend the first one for large projects, especially when the CVF project already used subdirectories for the source files. But keep the old CVF project, just in case. IVF catches much more syntax errors than CVF, so don't be disappointed when you get a long list of errors and warnings which were not present under CVF.

[Les_Neilson]

Chris
I hesitated on commenting about the commandline setup you have as I don't have experience of doing things that way. Generally I am the pioneer/leading edge/guinea pig here on installing new stuff; eliminating any problems (probably 99% of code changes when upgrading VisualStudio and IVF are due to C++ compiler "improvements"!) So I got to upgrade our many projects from Compaq to IVF. Being "many" it wasjust a matter of going through eachproject one at a time, after a few it became semi-automatic (i.e. I stopped thinking!), so that when the rest ofour development team upgraded the conversion was already done.

Our projects are a mixture of dlls, static libs, and exes (Fortran, C, C++ and lately C#) Some are pure (one language) but a lot are mixed.

Les

[chris-sn]

Les, I know what you mean on upgrades and C++ improvements....been there, done that...

Just on your last sentence, when you say you have mixed projects, you mean in the sense of the paper you recommended. i.e. each mixed project is implemented as two projects with a dependency?

Chris

[Les_Neilson]

By mixed I mean that the two languages are part of the same "solution" but each hasits own "project".
I just happen to be working on a "mixed language" project at the moment. The code directory has both C++ and Fortran source files in the same directory.

There isa solution file ListExport.sln containing two projects :
ListExport.vcproj which is C++
and ListExport_lib.vfprojwhich is Fortran

The fortran project is a static library configuration type, and builds libs to debug/ListExport_lib.lib and release/ListExport_lib.lib (where debug and release are subdirectoriesof the code directory)

The C++ project, under Properties->Linker->General has "Link Library Dependencies" set to "Yes" which causes the build to link in the fortran lib with the C++ code tomake ListExport.exe

HTH

Les

[IanH]

The custom build step way of forcing mixed languages into the one project seems like a maintenance hassle. I'm interested in the benefit you see with it?

Beyond CVF conversion issues - implicit in Les's posts is that the static libraries built by the single language projects are just simply building blocks for whatever you are ultimately trying to build, ie:

static-library-from-project1 + static-library-from-project2 + some-code-from-project3 -> dll-built-by-project3

Project3 depends on project1 and project2, and needs to be aware of any link requirements for its component static libraries. You also need to ensure that all component projects have consistent options for things like the runtime libraries. (These requirements also apply to your custom build-step approach.)

The language for project3 is normally based on the interface language for the DLL (with the source code in project3 being the interfacing code) - in your case that's C++ (?). Because obj's from fortran code need to be linked against both the Fortran and C libraries it is easier to have a fortran project build the DLL - C++ projects won't know where to go looking for fortran runtime libraries etc so you may need to set a path or two in the linker properties for the C++ project.

An omission in all this inter-project business is actually when fortran projects depend on other fortran projects. This pattern is often used when you want to isolate platform/compiler specific code (often present when you are writing interfaces to other languages in DLL's - all that !DEC$ nonsense) from otherwise standard Fortran code. While the static library from a child fortran project gets magically linked in when linking the parent project output, the directory that contains any mod files produced by the child project needs to be manually added to the parent project properties to allow the parent project to compile in the first place. This is a fiddly nuisance, especially once you start throwing various compilation configurations into the mix.

[chris-sn]

Thanks Ian,

"The custom build step way of forcing mixed languages into the one project seems like a maintenance hassle. I'm interested in the benefit you see with it?"

Firstly, simply that is the way they are currently constructed and working. Secondly, the C++ wrapper is extremely small and barely seems worth a separate project. I do accept that these reasons are both weak, and some experimentation is called for.

However...

I did my first trial compilation with the new compiler yesterday and am feeling rather daunted at the number of error messages, especially as the last serious FORTRAN programming I did was in FORTRAN IV.I better gofind outwhat the errors are all about first... :-(

[IanH]

Firstly, simply that is the way they are currently constructed and working. Secondly, the C++ wrapper is extremely small and barely seems worth a separate project. I do accept that these reasons are both weak...

There's nothing wrong with either of those reasons! Perhaps consider separate projects if the complexity of the C++ source increases in the future. Good luck with your use of fortran from this millenia.