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).




--
sane-devel mailing list: [email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
            to [email protected]

Reply via email to