[sane-devel] Getting ready for sane-backends release

[Olaf Meeuwissen]

Hi Johannes,

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
  GNU/Linux 8.8.

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
autoreconf then.

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
`autoreconf`.

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