RE: portability

[Steve Zabinsky <stevez@microsoft.com>]

What I wanted when I wrote (more or less) standard ANSI FORTRAN77 was
portable code in the sense that we could ship source code in one file that
everyone could compile using their own fortran compiler on their own
machine.

I assumed that people had a fortran compiler and could use it to compile and
link a fortran program that was self-contained, that is, in one file.

This was so that we did not have to ship executables for a kazillion
different platforms. The exception we made was for the PC running windows,
which did not have an easy-to-use fortran compiler at that time, plus there
were a LOT of these around.

I don't know what the current situation is with respect to fortran
compilers, nor how distribution is working now. It seems that it is easier
to ship source in an easy-to-compile form than to ship executables for
various platforms. Remember that if some not-implemented fortran feature is
used and someone can't build the program someone is going to have to provide
support...

Note that none of this has anything to do with setting up a useful build
environment. While people got that warm fuzzy sense that there were no
secrets because they had the source code, if anyone wanted to do development
on it we sent them our internal source (many files, include statements,
etc).

So here's a question for Linux fans -- how does an open source project
handle build environments and version control? This seems to be the topic of
the current discussion and the open source movement has probably worked out
solutions. Anyone know what they are?

Steve Zabinksy

-----Original Message-----
From: Matt Newville [mailto:newville@cars.uchicago.edu]
Sent: Wednesday, March 07, 2001 5:02 PM
To: FEFF Software Development
Subject: Re: portability


Hi John,

> Zabinsky took great care to keep the non-standard extensions
> in FEFF to a tolerable minimum: e.g., from the FEFF6 doc: "FEFF
> is written in ANSI FORTRAN 77, with the non-standard extension
> of double precision complex (complex*16) variables." Thus, the
> distributed code never had include files, nor end of line
> comments; they were allowed only for development purposes. I
> have tried to insist on keeping Steve's standards in subsequent
> developments of the code, and they have served us well.

What is "a tolerable minimum"?  It seems that complex*16 is required
and include files and end-of-line comments are not tolerated.  Why?
Zabinsky wrote that in (or before) 1993, before g77 was stable or
included with gcc.  So, how long will this definition be valid?

Why are there different 'developers' and 'distributed' versions?

> In my view portability concerns override strict adherence to the
> "standard," so as compilers improve past restrictions can be
> eliminated.  Only a year or so ago, we did release an
> experimental beta-version of feff8x with the include file dim.h,
> and quickly got complaints from a few users with compilers that
> didn't tolerate it. There is also a great temptation to use
> architecture specific utilities, but in my view this should be
> discouraged in view of the extra effort required to debug
> eventual problems. Thus I think it's preferable for everyone to
> work with the same set of codes.

Hmmm, not sure what you mean by 'architecture specific utilities'.
One might interpret that as wanting to avoid code that is sensitive
to the machine specifics like how many processor are available in a
machine.  Is that what you meant?

> In future developments of the code and derivatives (e.g., for
> components of a solid state toolkit) these portability concerns
> will continue to be important. Thus as a goal, I think it is
> desirable to be able to have build and compile Makefiles that
> are portable,

Makefiles are not portable.  Make is a Unix program, and assumes a
Unix-like development environment, and does not address portability
between different Unixes. Configure addresses portability between
different Unixes, but may not help with VMS, OS2, Amiga, Win32 or
Mac (unless you count CYGWIN and Mac OS X).

If portability is the main goal, and the ANSI F77 standard the only
route to that end, then you may want to abandon make and provide
compilation instructions for every machine or expect the user to
know how to use their Fortran compiler (and assume they have one!).
Then the code would be portable just like Feff6.  <wink>.

I think portability is a poorly defined and overemphasized goal.
Feff should work on all Unix-like systems, and ports to Win32, Mac
and VMS should be straightforward (and should DEFINITELY use
OS-specific code to avoid the ridiculous 'standard F77' behavior
that currently has to be tolerated on Macs).  I would not assume
that getting Feff to work on CP/M, AS/400, VxWorks, PalmOS, or
Playstation2 is a priority, but I've been wrong before.

--Matt

|= Matthew Newville        email: newville@cars.uchicago.edu
|= GSECARS, Bldg 434A      voice: (630) 252-0431
|= Argonne Natl Lab        fax:   (630) 252-0443
|= 9700 South Cass Ave     http://cars.uchicago.edu/~newville/
|= Argonne, IL 60439 USA