The clean target
rob.taylor at codethink.co.uk
Wed Mar 14 04:26:23 PDT 2007
Richard Hughes wrote:
> On 14/03/07, Stepan Kasal <kasal at ucw.cz> wrote:
>> I noticed that the MAINTAINERCLEAN variable contains Makefile.in,
>> at least in some subdirectories. (One of the side-effects of the
>> gtk-doc patch, if I have not missed something.)
>> I do not think this is right, the `maintainer-clean' target should
>> leave the tree in a state when ./configure is possible.
> I always use as a general rule:
> make clean: removes all generated stuff not in a tarball, still allows
> user to ./configure
> make distclean: removes all generated stuff not in VCS, user has to
> make maintainerclean: removes some stuff that might need odd tools to
> generate, like firmware headers and the like. User needs ./autogen.sh
> and some odd other tools.
> Maybe there's a more concrete rule of thumb on the net somewhere, but
> I always thought maintainerclean nuked everything not code.
Not quite right there, Richard ;) see
Delete almost everything that can be reconstructed with this
Makefile. This typically includes everything deleted by distclean, plus
more: C source files produced by Bison, tags tables, Info files, and so on.
Delete all files in the current directory (or created by this
makefile) that are created by configuring or building the program. If
you have unpacked the source and built the program without creating any
other files, `make distclean' should leave only the files that were in
the distribution. However, there is no need to delete parent directories
that were created with `mkdir -p', since they could have existed anyway.
* If make built it, and it is commonly something that one would want
to rebuild (for instance, a .o file), then mostlyclean should delete it.
* Otherwise, if make built it, then clean should delete it.
* If configure built it, then distclean should delete it.
* If the maintainer built it (for instance, a .info file), then
maintainer-clean should delete it. However maintainer-clean should not
delete anything that needs to exist in order to run ./configure && make.
We recommend that you follow this same set of heuristics in your
More information about the hal