This script serves the dual purposes of installing the initial instance of CUTEr on your system and of installing an additional instance, for a different architecture, where by architecture, we mean the combination machine-operating system-compiler-size-precision.
Assume, for the purpose of an illustration, that you wish to install all your different instances of CUTEr in the directory $CUTER = /usr/share/cuter/. Unpacking the CUTEr distribution in the $CUTER directory and launching the initial installation, say for the SUN Ultra machine, is done by simply typing
prompt% install_cuter
at the command prompt. However, before issuing the install command, we recommend that you check the files system.cf, where `system' represents your operating system, to make sure the commands there are correctly defined for your environment, and that the temporary directory is correctly set. The current directory `.' must not be used as temporary directory. Once you have issued the install_cuter command, you will be prompted for information regarding the instance of CUTEr you wish to install. The first question concerns your machine. In this case, select ``Sun workstation'' (7). Next, select the operating system your machine is running. Here, we select ``Solaris'' (1). You are then faced with a list of available Fortran compilers for your machine (without any guarantee that these compilers are actually installed on your machine, simply those we know are available for the machine-operating system combination you have selected)--we want to select ``Sun f90'' (4)--and a list of available C/C++ compilers for your machine--we select Sun Workshop6 C++ (2). Select next the precision of the CUTEr tools (single or double), and their size (small, medium, large or customized).
Once this information has been provided to the installation script, you are given a default directory name where the selected instance of CUTEr will be installed. This directory is a subdirectory of $CUTER that you chose earlier (in this case, /usr/share/cuter/). For the present instance, the default directory is
/usr/share/cuter/CUTEr.large.sun.sol.f90
reflecting the selections you made during the early installation phase. This directory name should be self-explanatory and should help you and other users determine where each installed instance of CUTEr is actually stored. Notice that the precision is not reflected in the directory name. The reason is that both single and double precision instances of CUTEr may be installed for the same machine-operating system-compiler-size combination; these will be stored in the single/ and double/ subdirectories of the above directory. If you wish, you may redefine the directory name and give it whatever name you like--it need not be a subdirectory of $CUTER. Note however that you should give the full pathname of the new directory that you choose, e.g.
/home/mjdpowell/software/yetAnotherCuter
even if this new directory is a subdirectory of the $CUTER directory:
/usr/share/cuter/aCustomCuter
It is probably good practice to be content with the default name or not to give it a cryptic or ambiguous name. After checks to see if a similar distribution has already been installed and for the existence of the specified directory, the installation itself begins.
The script install_cuter then creates the necessary directory structure, Umakefiles and configuration files. The final step of the installation is left to the user and is described below.
Once this phase is complete, install_cuter reminds you of what you should add to your .cshrc, .bashrc, or whichever UNIX configuration file corresponds to the shell you use. The directory structure after the initial installation is as described in the CUTEr paper provided in the CUTEr distribution and in §1.2 and Fig.1.1. In the case we are concerned with, the CUTER environment variable should be set to /usr/share/cuter and MYCUTER to /usr/share/cuter/CUTEr.large.sun.sol.f90 (or the alternative directory you specified during the installation phase).
install_cuter also advises you to read the various README files scattered over the directory tree under $MYCUTER. We now describe the final step of the installation using Umakefiles. There is a Umakefile in each subdirectory of $MYCUTER. Each of these Umakefiles needs to appropriately use the configurations files stored in $MYCUTER/config so as to generate Makefiles suited to your local system. This process is usually referred to as bootstrapping1.1. This is done by changing to $MYCUTER and issuing the command
prompt% ./install_mycuter
at the command prompt. Please note that if both single and double precision were installed, the script install_mycuter requires a command-line argument, telling it for which precision it should bootstrap the Umakefiles. In an attempt to follow the main guidelines for the CPP -- the C preprocessor, on which Umakefiles are based -- the argument to install_mycuter takes the form of a symbol definition. More precisely, if the user wishes to remake the double precision version of CUTEr, the command is
prompt% ./install_mycuter -DDoublePrecision
and similarly, for the single precision version,
prompt% ./install_mycuter -DSinglePrecision
Refer to the file IMPORTANT for the latest details. Do not let make's output confuse you. On a LINUX system, and because make is usually accompanied by the -w command-line option, using the standard g77 compiler, the output of the above command looks like
umake -I./config -DIsg77 -DLargeSize -DDoublePrecision + /bin/rm -f Makefile.bak + /bin/mv Makefile Makefile.bak umake -I./config -DTOPDIR=. -DCURDIR=. -DIsg77 -DLargeSize -DDoublePrecision making Makefiles in bin... make[1]: Entering directory `/home/do/Cuter4Linux/bin' make[1]: Nothing to be done for `Makefiles'. make[1]: Leaving directory `/home/do/Cuter4Linux/bin' making Makefiles in double... make[1]: Entering directory `/home/do/Cuter4Linux/double' making Makefiles in double/bin... make[2]: Entering directory `/home/do/Cuter4Linux/double/bin' make[2]: Nothing to be done for `Makefiles'. make[2]: Leaving directory `/home/do/Cuter4Linux/double/bin' making Makefiles in double/config... make[2]: Entering directory `/home/do/Cuter4Linux/double/config' make[2]: Nothing to be done for `Makefiles'. make[2]: Leaving directory `/home/do/Cuter4Linux/double/config' making Makefiles in double/lib... make[2]: Entering directory `/home/do/Cuter4Linux/double/lib' make[2]: Nothing to be done for `Makefiles'. make[2]: Leaving directory `/home/do/Cuter4Linux/double/lib' making Makefiles in double/specs... make[2]: Entering directory `/home/do/Cuter4Linux/double/specs' make[2]: Nothing to be done for `Makefiles'. make[2]: Leaving directory `/home/do/Cuter4Linux/double/specs' make[1]: Leaving directory `/home/do/Cuter4Linux/double'
This is normal output and it indicates that everything worked out smoothly. make is simply echoing what it attempts to do in each subdirectory. A message like ``Nothing to be done for `Makefiles'.'' simply indicates that the subdirectory where make is currently working does not have further subdirectories. On most systems, make is less verbose.
The above command should be able to properly generate the Makefiles in each subdirectory. These Makefiles should also only contain standard commands, as every effort has been made to avoid using exotic Makefile features and capabilities, such as the $@@ construct. A README file accompanies every Makefile to describe what it does and which targets it recognizes. Users are advised to take a look at these files. The documentation files and a basic knowledge of make should be enough for you to feel comfortable with the (re)generation of the various parts of CUTEr. Once the Makefiles are generated, the only thing that remains to be done is the usual make all. However, as users who have some experience with make know, make outputs a lot of information--it basically echoes to the standard output every action it takes. The -s command-line option to make lowers its verbosity level and basic information on how the build progresses only is printed. Thus, users should build CUTEr using the command
prompt% make -s all
This command completes the installation of CUTEr, using Umakefiles. On my Linux system, the installation takes a couple of minutes and make's output looks like
Getting UNIX commands right [Ok] Casting script.sed [Ok] Casting cast.sed [Ok] Casting local.f [Ok] Adding timer [Ok] Building local.o [Ok] making all in ./bin... Casting cob [Ok] Casting fil [Ok] Casting gen [Ok] ... ... ... Building uofg.o [Ok] Building uprod.o [Ok] Building ureprt.o [Ok] Building usetup.o [Ok] Building ush.o [Ok] Building uvarty.o [Ok] Archiving libcuter.a [Ok] making all in double/specs...
On workstations, the installation should be expected to take longer. During this phase, keep an eye on the screen and look for the [Ok] indicators. Should make come across some difficulty, this sequence of indicators should be interrupted by an error message. To know more about the problem, read the README file in the directory where the problem occured to try to indentify the target which make was attempting to build, and re-run make on that target without the -s option.
You may then install a new instance of CUTEr, which may be for a different architecture, or one corresponding to an already-installed instance, with a different precision or size. In all cases, the environment variable MYCUTER should point to the current, working, instance of CUTEr.
The install_cuter script keeps track of all installed instances of CUTEr on your system in the logfile $CUTER/log/install.log. This file may be used, for instance, to have MYCUTER point to the right distribution. For the purpose of illustrating the above, assume the three distributions given in Table 1.1 are installed in their default directory. Besides date information, the following will be found in $CUTER/log/install.log, where the exclamation mark (!) is a separator.
| double large Sun-workstation sol f90 | ! | $CUTER/CUTEr.large.sun.sol.f90 |
| double medium Intel-like-PC lnx g77 | ! | $CUTER/CUTEr.medium.pc.lnx.g77 |
| double large Compaq-Alpha t64 f90 | ! | $CUTER/CUTEr.large.alp.t64.f90 |