RE: portability

[Matt Newville <newville@cars.uchicago.edu>]

Hi Steve,

The one-source file model works fine assuming:
  1. one language is used, and that language is fortran.
  2. people have and know how to use a fortran compiler
  3. there is one (or a small number) of programs to be
     built, and not a library.
  4. development is expected to be fundamentally different
     from use.
Like you said, the one-source file makes customization and
co-development difficult.  It made sense in 1993 for Feff5, and
probably in 1996 for Feff7. I'm not sure it makes sense in for
future versions of Feff.

In the open-source community, one assumes a unix-like environment,
leaves code broken apart as if ready for development, and tries to
make the build procedure to go like this:
  1. set some small set of local parameters  like code
     limits and where installation files go.
  2. type some variation of
     configure ; make ; make install

The setup is often a set of switches to configure, but can also be a
small file to edit.  By tradition, configure is a Bourne shell
script (highly portable across Unixes) that determines system
settings (where is cc, where is ld, am I hpux or solaris?) and
creates the Makefiles from skeletons according to these settings.
The expectation is that code is in C, which requires system-specific
settings (where is string.h, how many bytes is an int?) that Fortran
cleverly <wink> avoids.

Configure scripts can get hairy, and painful to create and maintain,
but there are tools to help this, notably 'autoconf', which builds
ready-to-ship-anywhere configure from a definition file.  There's
also an 'automake' to build the skeleton Makefiles (from even
smaller skeletons!).  It's some work to set up, but once you have it
working it's not too difficult to maintain.  Now that g77 is a part
of standard gcc, these tools have started to support fortran.  No
one is extremely happy with configure, and there are attempts to
come up with something better:  someday an XML-based registry-like
database will be used everywhere, and everything will work
perfectly, just like NT4.0 <wink>.

For version control, CVS is the standard.  It is multi-developer
friendly and works very well over networks.

--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