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

[r. a. schmied]

Olaf Meeuwissen wrote:
> 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
> 

aloha olaf and interested saners

i've got one of those out-of-band systems (sun solaris 10 sparc update 8).
this is a very brief list of my handling of issues with configure as
shipped and possibly with configure.ac after this change takes place.
nothing that cannot be overcome.

when i run configure i have to set loads of envvars to set things right
but something i've been unable to fix with the current autotools system,
well two things:

1) to get a clean compile of umax_pp.c i had to add -D_XPG6 for gcc 4.9.0
   and my system to compile.

   i'm still unsure why any of the umax stuff is being compiled as that
   backend is not a listed backend unless it is needed for test or net.

2) my os has libusb at /usr/sfw/lib and provides /usr/sfw/bin/libusb-config
   to get the libs and cflags much like pkg-config does.  i've been
   struggling to get a workable set of autotool macros to work around
   this problem.  i think i have a partial solution but it re-instates the
   current override to always use pkg-config for 2 specifically listed
   systems.  i can provide these autotool changes if you are interested.
   (ax_path_generic.m4 and ax_compare_version.m4 added to m4, 25 lines
   or so added to configure.am.  also i've not yet been able to get test
   compiles or test links to work for this hack -- i'm expecting the book
   'autotools: A Practioner's Guide' to be delivered in the coming week.)

   the only thing i really needed to change after running the standard
   configure with my manual settings for USB_CFLAGS and USB_LIBS was
   ./include/sane/config.h:
      comment out: /* #define HAVE_LIBUSB 1 */

      insert: #define HAVE_LIBUSB_LEGACY 1

   this was trivially done following configure with an edit-in-place
   sed command (15 lines as bash script).