There is one file to download for the libGPF library - GPF.tgz . This includes
My own FAQ on Fortran is also available, with links to other Fortran resources.
Assuming a recent version of gfortran is on your system you can download the file and place it in an empty directory and enter
tar xvfz GPF.tgz
# if you are not on a platform with X11, ncurses, readline, and
# sqlite you might have to remove some of the files from the
# Makefile, and change the compiler and loader options if not
# using gfortran(1) and gcc(1). It is usually easiest to try
# it and then handle any failures individually ...
make
# you might want to edit hershey.sh to select where hershey
# font files will be installed (default is /usr/share/hershey),
# and then enter ...
bash hershey.sh
# if you do not have bash or a Posix shell you will have to run
# the h2v program for each font, as illustrated by the simple
# hershey.sh script.
# By default, the graphics routines require X11, the ncurses interface
# assumes libncurses is installed, the SQLite3 interface needs the
# libsqlite3 library, and the readline interface needs libreadline.
# These libraries are commonly available on many platforms but you
# may have to remove some of the files from the makefile and the
# compile if you do not want to build those interfaces, or install
# these libraries.
This will compile the GPF procedures and sample utility programs.
For other programming environments you will need to change the lines in the Makefile that define the compiler command. Many Fortran 2003 features are required. Recently, I have only tested with GNU Fortran (GCC) 7.3.0 .
Note to run the graphics programs you generally have to set some environmental variables. Some examples:
export M_DRAW_FONTPATH=/usr/share/hershey
export M_DRAW_DEVICE=X11
export M_DRAW_OUTPUT=out.pdf
or
export M_DRAW_OUTPUT="|ppmtogif > out.gif"
# Totally optionally, to build all the sample programs including
# the small sample programs from the man(1) pages
#!/bin/bash
make PROGFILES="$(find PROGRAMS -name '*.f90' ! -empty)" -j 10
The man(1) pages are particularly useful when working with the code files when used with editors such as vim(1) and emacs(1). Several editors can now look up and display the man(1) pages for a routine from inside the editors. Place your cursor over a function name in the example programs and enter "K" in vim(1) to access the man(1) page for a procedure, for example. Typically, you set the MANPATH environment variable to include the full pathname to the man/ directory first. Something like
export MANPATH=/home/$USER/GPF/man:$MANPATH::
(assuming you installed the source in /home/$USER/GPF)
will work, depending on what shell you are using.
HTML documents are the most complete reference, as they include some higher-level overviews of the larger module files that are not currently included in the man(1) pages. Otherwise, the HTML documents are for the most part generated from the man(1) pages.
Special HTML files use javascript to append groups of the HTML documents into a single manual.
Most of the code is maintained using a custom programming environment. The original source files are mostly ufpp(1) input files and/or HTML documents. To eliminate the need to install this custom environment all the source files have been expanded to standard Fortran and C source.
To simplify building the resulting collection of code a make(1) file has been automatically generated using makeout(1) to compile the sources.
Using a variety of utilities (primarily ufpp(1) and txt2man(1) ) the help text is generally part of the source file and automatically converted to comments, flat text, HTML and man(1) pages.
For those interested (particulary since ufpp(1) is one of the utilities included in this collection) most of the source is kept as ufpp(1) files. ufpp(1) can write text blocks to various files. This allows basic documentation to easily be maintained with the source. These blocks are then converted either into comments or help functions in the code by ufpp(1), but also optionally written to a common directory where they can be further processed, if required (they might already be HTML, which generally does not need further processing). For simple routines the documentation is often written to look like a flat text version of a man(1) page; which has proven to be a good standard for documenting procedures, which many people are familiar with, and integrates into Unix/Linux environments and tools. The txt2man(1) utility is used to convert the flat files to *roff files; other files are run thru markdown(1) or LaTex(1) or other utilities as appropriate, based on the suffix of the files.
The utility groff(1) was originally used to convert the man(1) pages to HTML and PDF but it has a bug as of this writing where it removes significant spaces when generating HTML; so the man(1) pages are now formatted using manserver.pl. Also see rman(1), html2man(1), and roff2html(1). It sounds complicated but is totally automated just using a few bash(1) scripts to glue it together, and provides for an easy way to maintain documentation and source in the same file.