[Top][All Lists]
[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