[MITgcm-support] Package configuration

Alistair Adcroft adcroft at MIT.EDU
Tue Sep 30 11:05:38 EDT 2003


We can talk about this tomorrow in our 10am meeting. When is Ralf around?

Here's a summary of discussions and suggestions for how to sort out the
package
configuration issue:

 o separate the package list from platform specific options
      i.e.  gm_local (formerly .genmakerc) ->  gm_local + packages.conf
 o gm_local can reside in source path or in ~/ /etc/ ...
 o packages.conf should reside in the source path (i.e. ./ code/) with an
order of
   precedence and is optional (the pkg_defaults are the norm)
 o syntax for packages.conf? Simplest to keep it like Ed's defaults list
      package or +package adds it the list
      -package deletes it from the list
   they always start from Ed's list of default packages but we should have a
"-all"
   which clears the list entirely for the rare occasion we are stripping out
everything.
 o maintenance of packages.conf would be easier if we define groups of
packages
   as part of the defaults (like aliases)
    e.g.  Ocean = +kpp +gmredi ... -aim ...
          Atmosphere = +aim23 ... -kpp -gmredi ...
          GFD = +mom_vecinv ... -kpp -gmredi -aim ...
          OfflineTracers = +generic_advdiff ...-mom_vecinv ...
    so that for an ocean experiment without kpp, packages.conf would contain
the line
            +Ocean -kpp
 o remove all mention of packages from CPP_OPTIONS.h
     (I've done this already in my WD and written a function for genmake2 to
check that
      CPP_OPTIONS.h is "legal".)
 o convert the three DISABLE_ flags to ALLOW_ flags
 o gm_ is an unfortunate choice of abbreviation?
 o edit the package specification document to reflect these changes

These address the current problems with package specification:
  x  recompiles everything every time we make makefile.
  x  lost information of where CPP_OPTIONS.h in compile directory came from.
     This particularly matters for non-repository files where the $Header
may be
     completely meaningless (i.e. copied from exp2 to somewhere else)
  x  mix of style of flags (ALLOW_ DISABLE_) due to old choice of which
packages
     were on of off by default. This happened for backward compatibility
reasons
     so that users did not have to change CPP_OPTIONS.h when we created
packages.
  x  no record of what code is compiled in stdout. The packages config stage
only
     reports what is enabled at run time, not what is compiled.
 (x) we should record the command line options somewhere (including CPP
defines).
     This is not packages related but does address the issue of no CPP
records.
  x  the package specification document reflects our thinking on this a day
     when CNH and I were sitting down at WHOI three (?) years ago and is
     propagating the notion that CPP_OPTIONS.h is the place for everything.

Partially related, we need to package certain things which are currently
controlled
from CPP_OPTIONS.h:
 o non-hydrostatic code (not a real package, but neither are mom_*). This
would also
   be an excuse to finish it...
 o ECCO!!!! There are #undef ALLOW_ECCO_PACKAGES in CPP_OPTIONS.h
   Which bits aren't packaged?
 o equation of state (we all agree)

A.
--
Dr Alistair Adcroft            http://www.mit.edu/~adcroft
MIT Climate Modeling Initiative        tel: (617) 253-5938
EAPS 54-1523,  77 Massachusetts Ave,  Cambridge,  MA,  USA





More information about the MITgcm-support mailing list