[sane-devel] Proposal to remove autoconf-generated files from the source repository

[Olaf Meeuwissen]

Hi!

TL;DR I am going to merge this shortly after 2019-06-12 10:00 UTC unless
someone raises objection here or in the [merge request][0].

 [0]: https://gitlab.com/sane-project/backends/merge_requests/72

Longer story follows below.

Povilas Kanapickas writes:

> Hi all,
>
> I propose we remove files from the source repository that are generated
> by autoconf and friends and ask the developers to do that.
>
> The primary motivation for this change is that the content of the
> generated files depends on the autotools version. Thus it makes harder
> for the developers to collaborate as they must use exactly matching
> autotools versions. Additionally the project history is cluttered by
> changes to the generated files, but we could perhaps live with that.

ACK.

> A PR has been opened here and received some discussion already:
> https://gitlab.com/sane-project/backends/merge_requests/72

Actually, Povilas and I have been hashing out and fixing up the
implications on the branch this merge request is about.  See the MR for
the gory details.

> We could keep inclusion of the generated files to the source tarballs
> that we distribute so that the recipients of the tarballs don't need to
> have autotools installed.

The current state (9c42d6ac) of that branch' CI only uploads source
tarballs created via `make dist` after they pass a `make` on all the CI
build environments.  These snapshot tarballs include all generated files
so people downloading them from the [project's website][1] do *not* need
any of the autotools.

 [1]: http://sane-project.org/snapshots/

# Official releases will of course include the generated files too.

However, if you clone the git repository (or download an archive of the
git repository via the GitLab web UI), you will have to run

 ./autogen.sh

before you can ./configure.  This is documented in the README as well.
The README also documents the extra tools you need.

> Additionally, this way we could be sure that this change does not
> break on weird platforms that we don't currently do testing on.

While working on this, we noticed that Alpinelinux does not provide some
of the autoconf macros we use to check for C++ standard's compliance.  I
have added a check for this to ./autogen.sh so people affected will not
be scratching their heads when running into this.  A failing check will
output instructions on what to do.

> The approach suggested in this email is how most projects that use
> autotools operate. We would be going through a common and tested path.
>
> Does anyone know reasons why this wouldn't work in our use case?

I don't and there was no-one flagging up anything for a week.

> Does anyone's workflow depend on autotools files being present in the
> default source checkout?

If so, you have two options:

 - use a source tarball instead
 - install the extra tools that are needed

# For the tech-savvy, you could untar the source tarball and move your
# .git/ directory into it and get away with *not* installing the extra
# tools.

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