Search code examples
autotoolsautoconfautomake

Modify make distclean so that it will delete .deps or *~ backup files

I did a make distclean on my project thinking it would really delete everything, but it left a .deps directory and it left all of my editor backup files.

I want to augment my ``Makefile.amin my project directory so that these are also deleted, but it's not clear to me how to do that. What additional things should I put inMakefile.am` so that the following are deleted:

.deps/
./autom4te.cache/
*~ (in every directory)
{project-name}-{majorversion}.{minorversion}.{release}. (releases that were attempted to be built)
Solution

  • I did a make distclean on my project thinking it would really delete everything, but it left a .deps directory and it left all of my editor backup files.

    The general rule implemented by the AutoTools is

    • if make creates it then make clean should clean it up.
    • if configure creates it then make distclean should clean it up.
    • if autoconf, automake, or one of the other AutoTools creates it, then make maintainer-clean should clean it up.

    Since you can inject arbitrary code into configure and into your makefiles, the AutoTools cannot ensure that that rule is universally followed, but the docs do recommend that you adhere to it.

    That your editor backup files are not cleaned up is to be expected. Such files are outside the scope of the rule for which targets clean what, and it is right and proper that the AutoTools don't try to guess about the significance of files that they have no role in creating or managing. They shouldn't have any built-in policy for what to do with such files.

    But if you want your particular project to have such a policy then that is within your control. Any or all of your Makefile.am files can add extra actions to be performed by make distclean by adding a distclean-local target. For example,

    distclean-local:
        rm *~

    Details of how to do similarly for other directories depend on how your project is structured.

    The autom4te.cache directory and its contents are a somewhat different story. This is primarily created and used by the AutoTools themselves -- autoconf, automake, etc. -- so naturally it is not cleaned by make distclean. Instead, per the rule, it is cleaned by make maintainer-clean. This is a bit blurry, though, because under some circumstances, make will re-run those tools. When it does so, however, it is in the context of those tools' inputs (Makefile.am, configure.ac, ...) having been modified, which is project maintainer activity, not project builder activity, so it's still reasonable to assign cleanup responsibility to maintainer-clean.

    Nevertheless, if you want distclean to clean up autom4te.cache then you can take the same approach as described for your editor backup files, though it's useful only in the top-level Makefile.am. For example,

    distclean-local:
        rm -rf autom4te.cache

    The .deps directory is a third story. It is created by make, so according to the rule, it should be cleaned up by make clean, whereas instead it is cleaned up by make maintainer-clean. That sort of makes sense, because the dependency information augments your makefiles and informs the build, and in principle, it could be generated some other way than as a side effect of building the project. It certainly should not be cleaned up when the object files are not, as that could cause subsequent builds to fail to re-make binaries that in fact need to be rebuilt. But if the object files need to be built anyway (because they are missing) then the dependency information will be rebuilt anyway, so there's no harm in having make distclean do this job. You can accomplish that analogously to the others.

    Finally, cleaning up distribution directories resulting from failed make dist or make distcheck runs. Preparing distributions is a maintainer activity, and although these artifacts are generated via the make tool, they are not produced by a default make run. I would put any cleanup responsibility for these on maintainer-clean, but I am uncertain whether it actually handles them. You can definitely follow the same approach as described for the other artifacts to get distclean to remove these. Do note, however, that

    1. You may need to perform a recursive chmod on these directories to grant yourself write permission before actually removing them, and
    2. You should take great care if you use glob patterns to perform the cleanup of such targets, because the nature of the naming creates a particular risk of accidentally matching files you wanted to keep.

    You can, of course, combine some or all of these (into one rule with a multi-line recipe) to add several of these behaviors to your project's build system.