[sane-devel] Getting ready for sane-backends release
paddy-hack at member.fsf.org
Mon May 15 11:33:09 UTC 2017
Johannes Meixner writes:
> Hello Olaf,
> On May 14 20:11 Olaf Meeuwissen wrote (excerpt):
>> Please run autoreconf on Debian GNU/Linux 8.8,
>> but only if you really, really have to.
> It seems the leading "Please" tells one should do it
> while the rest tells one should better not do it.
That's just me having trouble communicating. What I meant to convey was
If there is a need to run autoreconf, then please do it on Debian
Hope that's clearer now.
> Simply put:
> Is running autoreconf good or bad in general?
As with all questions, that depends. Even more so if you start taking
about the options it takes.
First of all, if you downloaded a source tarball for a release there is
no need to run autoreconf. All the derived files should be up-to-date.
For the snapshot tarballs the situation should be the same, ideally.
Occasionally there may be some inconsistency and you might want to run
For binary package maintainers, your distribution's documentation should
have information on what needs to be done. Some require you to update
config.guess and config.rpath to their latest versions and/or that you
rerun autoreconf. If you have any patches that change Makefile.am
files, configure.ac or acinclude.m4, then you should run autoreconf.
If you make changes to any of the Makefile.am files, configure.ac or
acinclude.m4 you should run autoreconf. Actually, we could make `make`
do so for you but a left-over from the CVS days in configure.ac disables
that (see AM_MAINTAINER_MODE).
I have been thinking of ripping that out but because we keep all these
generated files in our git repository I'm hesitant to do so. You see,
the content of generated files depends to a fair extent to the version
of the autotools used when running autoreconf. If developers start
running autoreconf every time a Makefile.am file's timestamp changes
(courtesy of running make and there doesn't even have to be a change in
content!), there will be a lot of churn in the derived files. If this
then gets committed to the git repository there'll be a lot of rather
irrelevant change. Personally, I'd rather not see that which is why I
would like to use a "canonical" environment whenever we need to run
Hope this helps,
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
More information about the sane-devel