[sane-devel] autoconf needs git clone

[Olaf Meeuwissen]

Hi Rolf,

Rolf Bensch writes:

> Hi Olaf,
>
> Debian and Ubuntu use autoconf for building their repositories. Since
> git commit bf00b9f49 they need a full git clone for running through
> 'configure.ac'.

Correct, mostly.  Running autoconf needs a repository checkout that
includes the most recent release tag.  This comes about because our
configure.ac now runs `git describe --dirty` to get the version.

Question: Why do Debian and Ubuntu need to run autoconf?

# I seem to vaguely(!) remember that there's a step to update the
# config.guess and config.sub scripts but our snapshots already include
# the latest, courtesy of tools/update-upstreams.sh.

> For my PPA I created a patch to revert this commit.

Meaning that your version becomes 1.0.27git.  Even for builds of 1.0.28
and later :-/

# Unless your "revert" is partial and inserts 1.0.28git or similar.

> On the other hand, after a git gull I always need to call './autogen.sh
> && ./configure' to see the updated git version in my manually builds, e.g.
> $ scanimage -V
> scanimage (sane-backends) 1.0.28-3-g90684c53; backend version 1.0.28

Correct, but if you are doing development anyway, wouldn't a `git
describe --dirty` be good enough to determine the version your working
with?  Do you really need `scanimage -V` to determine the version?

I admit it is a (minor?) workflow change, but it sure beats running

  ./autogen.sh
  ./configure.status
  ./make
  ./frontends/scanimage --version

which takes like forever.

# Actually, your git tool of choice will tell you in a split second what
# version you are on.  Making the backends and frontends actually use
# that is another `make` away, of course, but is that really necessary
# during development?

> This is annoying any I think you had another idea behind your commit.

The idea behind the commit was mostly to simplify creation of properly
versioned snapshots.  If people build from snapshots, their backends and
frontends should report the snapshot's exact version without the need
for anything extra (and do a better job than reporting something like
1.0.28git).  What we have in the repository now achieves that.

If people push branches, the snapshots for these branches will also
report a version that maps to a commit in the repository without any
extra work.

The only case that is not covered is the one you mention.  IIRC, there
is an autoconf-archive macro somewhere that does the Right Thing, but I
think you would get annoyed very fast when `autoconf` gets run everytime
you make a minor code change.  Fix a typo in INSTALL.linux, run `make`
and `make` will start with running `autoconf` ... not my idea of fun.

Also, using that macro would probably (haven't checked) require that
people using our snapshots checkout the repository *and* install the
autotools.  I don't think we want to require the occasional source
compilers to do that.

All that said, I'm open for suggestions to improve the situation.
Perhaps this is better suited as an issue.

> Hope this helps.

It does and I hope this helps too :-)
--
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