--- MITgcm/doc/devel_HOWTO.sgml 2003/08/20 19:47:14 1.2 +++ MITgcm/doc/devel_HOWTO.sgml 2003/08/28 22:44:00 1.3 @@ -398,10 +398,304 @@ - Coding + Coding for MITgcm + + + Build Tools + + Many Open Source projects use the "GNU Autotools" to help + streamline the build process for various Unix and Unix-like + architectures. For a user, the result is the common "configure" + (that is, "./configure && make && make + install") commands. For MITgcm, the process is + similar. Typical commands are: + + +$ genmake -mods=../code +$ make depend +$ make + + + The following sections describe the individual steps in + the build process. + + + The <filename>genmake2</> Utility + + Please note that the older + genmake is deprecated and will eventually + be replaced by genmake2. This HOWTO only + describes the newer tool. + + The first step in any MITgcm build is to create a + Unix-style Makefile which will be parsed + by make to specify how to compile the + MITgcm source files. For more detailed descriptions of what + the make tools are and how they are used, please see: + + + + http://www.gnu.org/software/make/make.html + + + http://www.oreilly.com/catalog/make2/ + + + + Due to the poor handling of soft-links and other bugs + common with the make versions provided by + commercial Unix vendors, GNU make + (sometimes called gmake) should be + preferred. + + As the name implies, genmake2 + generates a Makefile. It does so by + first parsing the information supplied from the following + sources + + + + a gm_local file in the current + directory + + + directly from command-line options + + + an "options file" as specified by the command-line + option -optfile='FILENAME' + + + + then checking certain dependency rules (the package + dependencies), and then writing a + Makefile based upon the source code that + it finds. For convenience with the various Unix shells, + genmake2 supports both "long"- and "shor"-style + options. A complete list of the available options can be + obtained from: + + +$ genmake2 -help + + + The most important options for genmake2 + are: + + + + + --optfile=/PATH/FILENAME + + This specifies the "options file" that should be + used for a particular build. The options file is a + convenient and machine-indepenent way of specifying + parameters such as the FORTRAN compiler + (FC=), FORTRAN compiler optimization flags + (FFLAGS=), and the locations of various + platform- and/or machine-specific tools + (eg. MAKEDEPEND=). As with + genmake2, all options files should be + written a BASH v1-compatible syntax. Examples of + various options files can be found in + $ROOTDIR/tools/build_options. Everyone is + encouraged to submit their options files to the MITgcm + project for inclusion (please send to + MITgcm-support@mitgcm.org). We are + particularly grateful for options files tested on new or + unique platforms! + + + + + -pdepend=/PATH/FILENAME + + This specifies the dependency file used for + packages. If not specified, the default dependency file + is $ROOTDIR/pkg/pkg_depend. The syntax for + this file is parsed on a line-by-line basis where each + line containes either a comment ("#") or a simple + "PKGNAME1 (+|-)PKGNAME2" pairwise rule where the "+" or + "-" symbol specifies a "must be used with" or a "must + not be used with" relationship, respectively. If no + rule is specified, then it is assumed that the two + packages are compatible and will function either with or + without each other. + + + + + -pdefault=PKG + -pdefault='PKG1 [PKG2 PKG3 ...]' + + This option specifies the default set of packages + to be used. If not set, the default package list will + be read from + $ROOTDIR/pkg/pkg_default. + + + + + -mods=DIR + -mods='DIR1 [DIR2 ...]' + + This option specifies a list of directories + containing "modifications". These are files that may + (or may not) exist in the main MITgcm source tree but + will be overridden by any identically-named sources + within the "MODS" directories. + + + + + + A successful run of genmake2 will produce + both a Makefile and a locally modified copy of + the specified CPP_OPTIONS.h file. The local copy + of CPP_OPTIONS.h will contain a list of + genmake2-created #DEFINE and #UNDEF statements + that reflect the list of packages that will be compiled into + the code (either directly through enable/disable/defaults + options or indirectly through dependencies). + + In general, it is best to use genmake2 on a + "clean" directory that is free of all source + (*.[F,f],*.[F,f]90) and header (*.h,*.inc) files. Generally, + this can be accomplished in an "un-clean" directory by running + "make CLEAN" followed by "make makefile". + + + + + Using <filename>Makefile</> + + Once a Makefile has been created, one can + build the executable using: + + +$ make CLEAN +$ make depend +$ make + + + The "make CLEAN" step will remove any local source + files, include files, and links. It is strongly recommended + for "un-clean" directories which may contain the (partial?) + results of previous builds. Such "debris" can interfere with + the next stage of the build. + + The "make depend" step will create a large number of + symbolic links from the local directory to the source file + locations. It also parses these files and creates an + extensive list of dependencies within the + Makefile itself. The links that exist at this + stage are mostly "large F" files (*.F and *.F90) that need to + be processed by a C preprocessor ("CPP"). + + + The final "make" invokes the C preprocessor to produce + the "little f" files (*.f and *.f90) and then compiles them to + object code using the specified FORTRAN compiler and options. + An intermediate script is often used during this stage to + further process (usually, make simple substitutions) custom + definitions such as variable types within the source files. + This additional stage is necessary in order to overcome some + of the inconsistencies in the sizes of objects (bytes) between + different compilers. + + Please report compilation failures or other problems to + MITgcm-support@mitgcm.org. + + + + + + + The Verification Suite + + The MITgcm CVS tree (within the + $ROOTDIR/verification/ directory) includes more + than a dozen examples intended for regression testing. Each one + of these example directories contains "known-good" output files + along with all the input (including both code and data files) + required for their re-calculation. These example directories + are further broken down into sets of subdirectories + (eg. /input, /code) intended to + expedite the testing process. + + + The <filename>testreport</> Utility + + Also included in $ROOTDIR/verification/ are + shell scripts for automated testing. The newest script (which + was written to work with genmake2) is called + testreport. Ths script can be used to build the + different versions of the MITgcm code, run the various + examples, compare the output, and (if specified) email the + results of each one of these tests to a central + repository. + + The testreport script accepts a number of + command-line options which can be listed using the + -help option. The most important ones are: + + + + + -tdir TESTDIR + -tdir 'TDIR1 TDIR2 [...]' + + This option specifies the test directory or list + of test directories that should be used. Each of these + entries should exactly (note: they're case sensitive!) + match the names of directries in + $ROOTDIR/verification/. If this option is + omitted, then all directories that are properly + formatted (that is, containing an input + sub-directory and example output) will be used. + + + + + -optfile=/PATH/FILENAME + -optfile '/PATH/F1 [/PATH/F2 ...]' + + This specifies a list of "options files" that will + be passed to genmake2. If multiple options + files are used (say, to test different compilers or + different sets of options for the same compiler), then + each options file will be used with each of the test + directories. + + + + + -addr EMAIL + -addr 'EMAIL1 EMAIL2 [...]' + + Send the results (namely, output.txt, + gm_local, gm_state, and + Makefile) to the specified email addresses. + The results are gzipped, placed in a tar file, MIME + encoded, and sent to an @mitgcm.org address. If no + email addresses are specified, no mail is sent. + + + + + + The testreport script will write progress + to the screen (stdout) as it runs. In addition, it will + create a summary.txt file that contains a brief + comparison of the current output with the "known-good" + output. + + + + - Coding Packages + Creating MITgcm Packages Optional parts of code have been separated from the MITgcmUV core driver code and organised into packages. The packaging