Fortran IDE's

[martymike]

Background:

-we are still running CVF 6.6 and Visual Studio 6.0

-we have a large mixed-language product (e.g. largest dll > thousand source files, 65% Fortran, rest C). Other parts of the product use C++ and Python as well, but still mostly Fortran.

-we have resisted upgrading primarily because of not wanting to deal with MS's .NET and having to separate that dll into C and Fortran parts (such a separation would create mutually dependent libararies, with many references between them)

Issue:

-clearly there are features and corrections, both in the language offerings and in the development environment, that we could use to our advantage

-support for these products, such as it is,with not last forever

Questions:

-what are our alternatives?

-Moving to Studio.NET is clearly one choice. Dividing the product up by source language appears to be a nightmare, and needlessly arbitrary. Also, the view from here is that the .NET technology itself is not much more than smoke and mirrors. Please argue with those comments, if you feel so inclined.

-Are there other IDE's that provide comparable visual debugging tools that you know your compilers work well with?

-Staying where we are is, of course, another choice. What problems do you forsee for us if we decide to be subborn about this?

I don't really want to stay where we are. For example, I have read in other posts that the nuisance of dealing with Studio's failure to recognize module file dependencies is corrected in the .NET version. I'm sure that that's not all. Also, I'm quite interested in using new language features as they are introduced, and some that already have been.

[durisinm]

You can stick with CVF and VS v6 forever as long as they continue to run on your computers. As you already noted, though, any known or yet to be discovered problems in those products won't be fixed, nor will you be able to take advantage of new features (like those coming from the adoption of the Fortran 2003 standard) that other compilers will be introducing.

VS 2005 (aka v8) is due out relatively soon; the beta may already be available. It may not require the separation of mixed language projects by language, but I doubt it.

I don't want to steer you away from IVF, which I consider to be the logical successor to CVF, but compiler makers like Lahey, Salford, NAG, Absoft, and IBM offer C and Fortran compilers with IDEs. I've never used any of them and therefore can't say anything about whether they're better or worse than CVF.

Mike D.

[Steven_L_Intel1]

VS.NET 2005 doesn't change the separate project requirement. But I don't think it's as bad as you suggest. There are a couple of ways I can think of to make sure that all the code from the library project is included. The first is to have external references to each of the library routines in the DLL project. Another is to use a .DEF file that names all the routines to be exported. Yet another is to have a post-build step that copies all of the .obj files into a single one that is linked in to the DLL. Yes, I know it's somewhat of a pain.

Lahey also uses VS.NET, so you'd have the same issue there. Plus, it's more expensive and the licensing is more restrictive than Intel's.

I think you can make it work with Intel Visual Fortran. We'll be glad to help you out if you get stuck.