Debugging the distcheck target
Here are common issues that can arise when you first run make distcheck
1 A file or directory does not exist
Symptom: You run the build (e.g., make check) and everything's fine, but make distcheck fails because a file or directory was not present.
Try: In the code, look for places where you used the autotools variable @srcddir@ (or @top_srcdir@ or @abs_srcdir@ or @abs_top_srcdir@) to refer a file or directory that is generated. In a regular build (e.g., make check) that will work fine since the src and build directories are one and the same. With make distcheck, not so much since the build (the generated) files are in a different directory from the source. To fix this, use @builddir@ (or the obvious variant).
2 A directory with generated content is not cleaned
Symptom: The make distcheck target complains that a directory contains files after the various clean operations.
Try: Add the latent files to the DISTCLEANFILES variable of the Makefile.am. Use a shell pattern to remove all of the files in a directory when the directory itself should not be removed. For example, DISTCLEANFILES=atconfig cache/*
3 The build fails because it cannot clean .deps
The exact message usually contains a long list of files in a directory named .deps and ends in could not delete .deps. The problem is that a child Makefile.am uses the AUTOMAKE_OPTIONS subdir-objects and the code references source or object files using ../file.o or ../file.cc. This causes the directory to run rm -rf ../.deps .deps and then run rm -rf .deps in the parent. But since the child already removed the parent's .deps directory, make reports an error since the parent's .deps dir no longer exists. The fix is to remove the subdir-objects option. In general, this option should be used only when building a source file in a child directory and you want the resulting object file to be put in the child dir too, and not the CWD.