Improve installation by consolidating Python scripts into autotools scripts

[baagaard-usgs]

Autotools integration

The combination of Python scripts and autotools (autoconf, automake, etc) introduces several issues from a developer and user perspective:

1. The Python scripts always run all steps. For example, the ucvm_setup.py script always starts from the beginning, even when some of the steps may have completed successfully.
2. The installation process involves running multiple scripts.
3. Combining Python scripts with autotools results in an installation process that is significantly more difficult to debug and diagnose errors. It is also much more cumbersome to maintain.

I suggest consolidating the installation process so that it is all done by autotools. This will provide better checking and error reporting and allow the entire installation process to be consistent and controlled by the top-level configure script.

Additional issues

• Using libtool to build the libraries allows static and/or dynamic libraries to be built in a portable way (for example, support both macOS and Linux). Currently, the Makefile.am scripts are hardwired to build shared libraries on a Linux system.
• Distribute code using tarballs that include the configure script. When using autotools, such a tarball is generated with the make dist command. This eliminates the need for a user to run aclocal, automake, or autoconf; a user just runs configure, make, and make install. Developers should only have to run autoreconf to generate the configure script.
• Separate the code for querying velocity models from the data files. The code for querying the velocity models can be released via normal GitHub releases; I highly recommend moving the models to an appropriate archive, like zenodo, and then use curl to download the data files during the make install script. This reduces the size of the tarballs and allows the data files to be installed directly to the installation location (minimizing storage requirements). This follows the model used by Proj for downloading the geographic datum information.
• The Proj library is installed without the datum grids. This introduces errors in the conversion routines. Additionally, the version of Proj being used is out of date (current version is 8.2.1). It would be a significant improvement if all of the SCEC maintained models used Proj for transforming to/from geographic coordinates. For example, CCA uses external Fortran code that has errors in it (see https://github.com/SCECcode/CCA/issues/1) and the cvmh code uses gctpc. which is not maintained and is over 25 years old). Note that Proj 8.0 requires sqlite and libtiff.

See https://github.com/SCECcode/cvmh/pull/2 for an example of how this can work. I am making the above changes for ucvm in a fork for the features/models I am using. I don't have time to fix all of the autotools issues for all of the models, but once you see an example, it is pretty easy to make the updates.

Edits

Jan 12, 2022: After working more with the UCVM source code, I understand how the plugin models work. I edited the comments above to remove my suggestion to integrate the code for querying the models (for example, cca) into the UCVM code base. I think it makes sense to be able to update the query code for the individual models without touching the UCVM repository.

[baagaard-usgs]

On a related note, I have created a repo for the Euclid software https://github.com/baagaard-usgs/euclid-etree and updated the configure.ac and Makefiles for better portability. One only needs to run autoreconf to generate the configure script. It builds and installs the etree library. The examples and tools can also be built, but they are not installed.