Xref: utzoo comp.lang.fortran:318 comp.sources.wanted:2817
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!udel!burdvax!sdcrdcf!csun!acphssrw
From: acphssrw@csun.UUCP (Stephen R. Walton)
Newsgroups: comp.lang.fortran,comp.sources.wanted
Subject: Re: ratfor to f77 preprocessor
Message-ID: <979@csun.UUCP>
Date: 21 Dec 87 22:38:10 GMT
References: <871218123142@euler> <254@tsc.DEC.COM> <871220161548@euler>
Reply-To: acphssrw@csun.UUCP (Stephen R. Walton)
Organization: California State University, Northridge
Lines: 15

In article <871220161548@euler> scott@bu-ma.bu.edu (Scott Sutherland) writes:
>The main problem here is when I want to
>use a debugger, in which case I have to compile by first getting
>ratfor to build a .f file, then invoking f77 on that file (so that the
>source matches the symbols built by the -g option). 

The f77 compiler on BSD and descendants actually understands the #
<line number> <file> construct of C, and so ratfor could theoretically
produce an object file which would refer to the ratfor source rather
than the generated Fortran.  Just a thought, for anyone who might like
to hack on it.  (I uncovered this fact when I tried to use the .F
extension, which causes f77 to run cpp on your Fortran source before
it is compiled.  Worked, except that I wound up with the name of the
generated .f file rather than the original .F file, which caused the
same problem Scott describes.)