QD

A double-double and quad-double package for Fortran and C++

End-user documentation

For historical reasons, the original user-focused documentation is located in the README file, sans the .md extension. In-depth technical documentation is also provided, as docs/qd.pdf in the release tarballs. To build the PDF from its LaTeX sources, run

$ make -C docs qd.pdf

after installing the necessary LaTeX bits on your system.

Tips for developers

Before you can build QD from the git repository, you will likely have to generate the "autotools" files (such as ./configure) that are normally provided for you in a release tarball. The easiest way to do that is to run,

$ autoreconf -fi

as a shortcut for running each of autoconf, autoheader, aclocal, automake, and libtoolize as many times as necessary and in the correct order. The -fi flags force autoreconf to regenerate everything, and to install any missing auxiliary files. You will of course need all of the relevant autotools packages (autoconf, automake, and libtool) installed for this to work.

Afterwards, you can ./configure the package and build it like you normally would from a release tarball.

Running the test suite

The QD library comes with an automated test suite that should always pass. To run it, execute make check after building the library. Ignoring the noise from the compiler (the test suite itself must be compiled), the output should look something like

$ ./configure
...
$ make
...
$ make check
...
PASS: qd_test
PASS: pslq_test
PASS: c_test
PASS: f_test
============================================================================
Testsuite summary for qd 2.3.23
============================================================================
# TOTAL: 4
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

Making a release

There are several steps that need to be performed when making a new release:

1. Ensure that all important user-facing changes are mentioned in the NEWS file.

2. Update the package version number in configure.ac.

3. Build a release tarball. First, run git clean -x -f -d to ensure that you're starting fresh. Then run autoreconf -fi to regenerate all of the autotools files. Run ./configure to create your Makefiles, and finally, make dist to create the release tarball.

4. Run make distcheck to ensure that the release tarball works.

5. Tag the commit that corresponds to the release with git tag -s <version-number>.

6. Push everything to Github.

7. Upload the release tarball (created earlier) to the Github release page that corresponds to your new version tag. This ensures that end-users can run ./configure and such "out of the box," without having to install the GNU autotools (or learn their commands).