My main concern here is for Mac OS X and all other case-insensitive OSes
(and what about OSes that go a step further and are fully case-unaware?).
I'm guessing they should work, but I imagine we'd have to test thoroughly
all platforms we currently claim to support in order to move over.
As a note of support which should make this transition easy (and addresses
one of Dave's initial arguments against the change), git should make this
painless. In the words of Linus, "Git tracks content, not files", meaning
that we won't lose all history on all files we change the name of (because
git doesn't care about individual files).
Since git can track the changes through filename changes, this transition
shouldn't be difficult (one of the many good reasons for switching away from
CVS and *not* going to svn).
I'm guessing the script only changes file names, right? It doesn't put into
motion the rest of your plan?
All the best,
Jason
On Mon, Oct 10, 2011 at 4:07 PM, Tyler Luchko <tluchko.rci.rutgers.edu>wrote:
>
>
> On 10/10/2011 03:43 PM, Ben Roberts wrote:
> > Hi Tyler,
> >
> > On 10/10/2011, at 3:29 p.m., Tyler Luchko wrote:
> >
> >> Hello Everyone,
> >>
> >> At the last developers meeting I proposed changing our Fortran file
> >> naming scheme from the generic '.f' to using '.F' for fixed format,
> >> pre-processed files, '.F90' for free format, pre-processed files and
> >> '.f' for fixed format files without pre-processing. As a result of this
> >> name change explicit calls to the C pre-processor would be removed and
> >> the compiler's built in pre-processor would automatically be called.
> >>
> >> The motivation for this change is:
> >>
> >> 1) Easier debugging as line numbers refer to the original source file
> >> and not an intermediate.
> >>
> >> 2) Eliminating intermediate files reduces clutter, disk space and,
> >> possibly, compile time.
> >>
> >> 3) This is a universal convention (though not part of an official
> >> standard) and has been in use for over a decade by many compilers. If
> >> we choose to move to a different build system (e.g. cmake) this will
> >> also help ease the transition.
> >
> > I like this idea. In fact, I started doing something similar myself a
> while ago, but at the time Dave Case argued against it. My motivation was by
> no means as strong an argument as yours; I was simply sick of my
> syntax-aware editors highlighting the free-format F90 source files as if
> they were fixed-format F77.
> >
> > There is one thing that you can perhaps clarify for us. Will this in any
> way change the syntax needed for #ifdef declarations and the like? And are
> there any disadvantages to using the Fortran preprocessor instead of the C
> preprocessor? I gather there is some reason why we've been explicitly asking
> for a C preprocessor instead of relying on the Fortran compiler's
> preprocessor; perhaps this reason is purely historical, though.
> >
>
> The short answer is that with the compilers that I have been able to
> test, GNU, Intel and PGI, everything works without modification. I
> would _expect_ this to be true for other common compilers as the
> convention is to use the C pre-processor, or something very close to it,
> but don't have the machines/compilers to test this.
>
> The long answer is different compilers do invoke different
> pre-processors. GNU, PGI and IBM invoke the C pre-processor. Intel, Sun
> and NAG have Fortran pre-processors that obey common C pre-processor
> directives and syntax but are not identical to cpp. For example,
> Intel's fpp does not support #pragma or #ident. As I said, of this last
> group I've only used Intel and had no problems with the current code.
>
> Tyler
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Oct 10 2011 - 14:30:02 PDT
