Feature #907

Add tests for verifying installed headers

Added by Teemu Murtola almost 9 years ago. Updated almost 7 years ago.

Target version:


With the new source code reorganization, where all headers are located in the same directory as the relevant source files, there is no longer such a clear separation between installed and non-installed headers. This makes it easier to make mistakes that break the installed headers, e.g., by forgetting to install a header that is referenced from another header, or by not referencing other headers by relative paths from an installed header. To avoid these issues, it would be good to have a test that checks the installed headers for consistency.

Things to at least consider adding in the test:
  • Check that all the headers included by installed headers are also installed and that the references work when the headers are installed. The easiest way is probably to install the headers to a path that is not in the include directory of the compiler, generate a source file that includes all the headers, and try to compile that.
  • As a more advanced version, the test could check that each installed header compiles in isolation. The same test as above, but generate a source file for each header that only includes that header, and try to compile each of these.
  • It would also be good to check that the provided template can be compiled and linked successfully against the installed headers, using the Makefile/CMakeLists.txt/pkg-config files provided with the template. Some other compilation/linking tests could also be good, although hopefully most errors will be caught already by the compilation of Gromacs programs during the regular build.

Associated revisions

Revision 06069731 (diff)
Added by Teemu Murtola over 8 years ago

Script for analyzing include dependencies.

Add a Python script plus some CMake code to run it that analyzes include
file dependencies. The script can also generate different kinds of
include dependency graphs (this implementation dates from a time when
some versions of Doxygen didn't do this properly, and the script still
has some features that Doxygen doesn't have). Some parts of the script
contain hard-coded stuff related to the Gromacs source tree layout or
the Doxygen guidelines, but the core dependency analysis should be quite

There is a lot to improve in the script (in addition to missing
features, docstrings and comments are sparse, and some parts could be
better structured), but it is already usable.

Fix a few issues that produce multiple warnings from the script, and one
issue found by the script (in helpformat.h).

Related to #638 and #907.

Change-Id: I22a6d6c0818f21c828f1e7d6beb1fdada39273d2


#1 Updated by Teemu Murtola almost 7 years ago

  • Tracker changed from Task to Feature
  • Project changed from Source code reorganization to GROMACS
  • Category set to testing
  • Status changed from New to Accepted
  • Target version set to future

Some checking currently exists in the form of make depcheck, but it should be integrated into Jenkins and improved to catch more issues.

#2 Updated by Mark Abraham almost 7 years ago

I have plans to work up my do-release scripts into a Jenkins test for deploying a full install, and some of these considerations will apply. Getting fewer nasty suprises when I come to build tarballs would be nice!

Also available in: Atom PDF