bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32074: maintainer-clean and removing configure/Makefile.in/etc.


From: Mathieu Lirzin
Subject: bug#32074: maintainer-clean and removing configure/Makefile.in/etc.
Date: Sat, 07 Jul 2018 11:53:48 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hello Karl,

Karl Berry <address@hidden> writes:

> Hi - the automake manual has (for many years) said:
>
>     @code{maintainer-clean} should not delete anything that needs to exist
>     in order to run @samp{./configure && make}.
>     @end itemize
>
>     We recommend that you follow this same set of heuristics in your
>     @file{Makefile.am}.
>
> That heuristic made sense when Francois formulated it decades ago. But
> nowadays, especially since autoreconf exists, it does not seem
> unreasonable to me to want to delete Makefile.in, configure, etc. It is
> just as easy to run autoreconf (or equivalent) as configure&&make, and
> it feels nice to have such dependent files gone from the source tree,
> especially when working on setting up a package with autotools.

What is not clear to me is the reasoning of that heuristic.  You seems
to suggest that it has been introduced to avoid having to know the order
in which autoconf, aclocal, automake, ... has to be run.  Have you any
reference regarding that?

I would guess that the reason is more that this command might be run
from a tarball and that if the package builder doesn't know that
Autotools is now needed as a dependency, that person is left without any
instruction regarding what to do.

> I certainly don't suggest changing any behavior, but perhaps the manual
> could mention that it could be done via maintainer-clean-local or
> MAINTAINERCLEANFILES, e.g.:
>
> MAINTAINERCLEANFILES = aclocal.m4 config.h.in configure \
>                        Makefile Makefile.in */Makefile */Makefile.in
>
> Some maintainers might prefer to also remove build-aux or more; personally
> that's one step too much for me. All the more reason not to change any
> code :).

Can you explain why this step would be too much for you?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37





reply via email to

[Prev in Thread] Current Thread [Next in Thread]