Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [photran] Photran 5.0 & Intel Visual Fortran 11

Bob Apthorpe wrote:
I'm migrating to Eclipse for most of my development on Windows and Linux
  for a number of reasons. It decouples the compiler from the IDE, it
gives me the the same toolset and IDE regardless of platform, it gives
me superior search-and-replace capability, and in the case of Photran,
I'm hopeful that the refactoring tools will mature to where I can press
a button and convert our fixed-format half-F77/half-F9x code to clean,
clear F9x code (I can dream... :) )

I'd like to second the value of a multiplatform IDE. As one of several developers on a million line code that is supposed to work on a number of systems (Win XP/XP 64/ Vista/Vista 64/Linux/Linux 64/Solaris/AIX/HP-UX/Mac OSX) it would be a huge win if I could abstract away the compiler and use a unified IDE, so I don't have to remember as much of the different nuances between VS, XCode, KDevelop and the command line ( it's surprising how much I still use command line tools...)

To my mind this would require 3 API s to provide a generic interface that could support varying backends-

1) configuration/build settings for platform dependent things and use of a build system (e.g. make, autoconf, CMake, SCONS, etc) Many of these tools have eclipse modules; I don't know to what extent these modules cooperate with CDT/Photran.

2) compiler API for both invocation and error parsing

3) debugger API.


If the CDT/Photran team(s) provided good implementations of the above ( I don't know to what extent these exist as a tool independent APIs) and a concrete implementation of them for atleast 1 toolchain (make, gfortran/g95, gdb) then the community could either work to provide implementations of these, or twist the vendor's arms to provide these for the other compilers / tools

To what extent are these APIs available or are the plugins written to take the button press all of the way to the tool in a single subroutine with no abstractions?


--
Russ Johns




Back to the top