This method of compiling and linking is fully supported. This is the procedure a developer will follow to work on one or more packages as a unit. End users who want to modify one or more packages for their own purposes can also use this technique. The simplest example of the directory structure is shown in Fig. 3 and a more complex example is shown in Fig. 4. In these figures Foo is developing code for package pkgB.
For example in Fig. 3, on a machine running IRIX, gmake
created the test release library for pkgB, ~foo/test/lib/IRIX/libpkgB.a,
and the test release executable for pkgB, ~foo/test/bin/IRIX/testB.exe. When
constructing libpkgB.a, all include files not in pkgB were taken from
$SRT_DIST/releases/$SRT_BASE_RELEASE/include/*, and when constructing
testB.exe all libraries other
than libpkgB.a were taken from
$SRT_DIST/releases/$SRT_BASE_RELEASE/lib/$SRT_ARCH. Similarly, in
Fig. 4, gmake created the test release library for
both pkgA and pkgB, and the test release executable for pgkB. Once again,
all include files not in pgkA or pkgB were taken from
$SRT_DIST/releases/$SRT_BASE_RELEASE/include/*, and when constructing
testB.exe all libraries other
than libpkgB.a and libpkgA.a were taken from
$SRT_DIST/releases/$SRT_BASE_RELEASE/lib/$SRT_ARCH.
However unless the user has specificied a "super" test environment via both the srt_setup and srt_super_init commands, gmake will look for header files and libraries in the <base-release>, found in the .current file, regardless of how the user has modified the environment via the setup command. Thus the SRT_BASE_RELEASE variable is redefined by gmake based on the contents of the .current file, and this redefinition only last for the duration of the gmake command.
In addition to established packages, the above steps can also be used to create your own package, or work area, and link it in with your test release. If you are creating a new package called work, in place of addpkg you will want to do a mkdir work, and copy your source files to the work subdirectory. In addition you will need to have a GNUmakefile similar to one that appears in the top directory of any of the packages. In that GNUmakefile you will need to specify the library name (where the object files go), and add this library to the list of libraries looked for in any link. If you are linking an executable associated with this work package, you will want to specify them in this GNUmakefile, and give the link command. For example, assume you have two files, test2.F containing a program test2, and test.F containing a subroutine test which is called by test2. You should make a library libwork.a to contain the compiled subroutine test, and link it to the main program test2, by adding the following lines to the package makefile specified in Appendix D.1:
LIB = libwork.aHere the first line specifies the the library as libwork.a. The second line indicates that all Fortran files except test2.F (the main program) will go in this library. Note that test.F is never mentioned explicitly, it is simply picked up from the area and compiled because it has the suffix .F. The third line adds libwork.a to the list of libraries to be loaded. The executable name test2.exe is specified in the fourth line. The fifth line says that the executable test2.exe depends on the main program file test2.F and the libraries. The sixth and seventh line give the rule to make the executable test2.exe (these lines are begun with a tab). Developers can add similar lines to their GNUmakefile, to construct executables from their own packages. If in doubt, copy from a GNUmakefile in an established package. When the new packages are fully tested, they can be migrated to the release.
LIBFFILES = $(filter-out test2.F, $(wildcard *.F))
override LOADLIBES += -lwork
BINS = test2.exe
$(bindir)test2.exe: test2.F $(LIBS)
echo linking test2 ; $(FC) $(FCFLAGS) $(CPPFLAGS) $(LDFLAGS)\
-o $@ $< $(LOADLIBES) $(LDOUT);