[sane-devel] Proposal to remove autoconf-generated files from the source repository
r. a. schmied
uwppp at flash.net
Sat Jun 8 17:31:32 BST 2019
Olaf Meeuwissen wrote:
> 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].
> : https://gitlab.com/sane-project/backends/merge_requests/72
> Longer story follows below.
> Povilas Kanapickas writes:
>>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.
>>A PR has been opened here and received some discussion already:
> 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] do *not* need
> any of the autotools.
> : 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
> 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
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).
More information about the sane-devel