automake-patches
[Top][All Lists]
Advanced

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

Re: distcleancheck.patch


From: Alexandre Duret-Lutz
Subject: Re: distcleancheck.patch
Date: 24 Nov 2001 02:12:23 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Hi Bruce,

>>> "Bruce" == Bruce Korb <address@hidden> writes:

[...]
 >> +find generated files that you forgot to add to the @code{DISTCLEANFILES}

 Bruce> Unlike MAINTAINERCLEANFILES, this one is named DIST_CLEAN_FILES.

That's really DISTCLEANFILES.  If you have seen DIST_CLEAN_FILES
somewhere it's a bug.

[...]

 >> address@hidden
 >> +distcleancheck:
 >> +        @@:
 >> address@hidden example
 >> +
 >> +If you want @code{distcleancheck} to ignore built files which have not
 >> +been cleaned because they are also part of the distribution, add the
 >> +following definition instead:
 >> +
 >> address@hidden
 >> +distcleancheck_listfiles = \
 >> +  find -type f -exec sh -c 'test -f $(scrdir)/@address@hidden || echo 
 >> @address@hidden'
 >> address@hidden example

 Bruce> I see how this works, but on the other hand, the Makefile.in output
 Bruce> file is generated from a Perl script.  As such, it really is not
 Bruce> terribly difficult to take this:

 Bruce> @exemple
 Bruce> distcleancheck_ignores_rebuilt_files = true
 Bruce> @end example

 Bruce> and massage it into doing the right thing. 

That means adding yet another cruftin automake, and then someone
will ask Automake to handle another hint like
  distcleancheck_ignore_these_files = foo bar baz
or whatever else, which means yet another special hack.
IMHO, there are already too much `if's in automake.

My proposal don't touch automake, it relies only on standard
mechanisms (target and variable overriding), and I find this
much more flexible that any specific option handling.

(There are other places in Automake where I'd love to see
options replaced by this kind of handling.  Selecting which
archive formats (tar.gz, tar.bz2, zip, etc.) are created by
`dist', for example, would be much more porwerful if it was not
handled through options.)

 Bruce> I am _very_much_ a believer in making things easy to use
 Bruce> for end users (e.g., me).

Is it really important to provide polished support for such an
uncommon need?  I still would like to see a case where it's
*necessary* for a freshly unpacked package to rebuild a
distributed file.  IMHO, such a package is probably tricky
enough so that hacking this particular definition is not a big
deal for the maintainer (e.g., you).

[...]

 Bruce> If it turns out that it is "hard" to make alternate text
 Bruce> based on clues like the above, then I have two
 Bruce> proposals:

 Bruce> 1.  do it as you suggest
 Bruce> 2.  add infrastructure so that it becomes easy.

Bruce, are you tired or what?  How can you write "make alternate
text based on clues like the above" and yet forget the ultimate
proposal: 3. use Autogen :)
-- 
Alexandre Duret-Lutz



reply via email to

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