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

Wed Jun 19 17:31:52 BST 2019

olaf interested saners

continuing:

> The autotools are a bit of a steep learning curve :unamused:

amen!

first: the submitted configure.ac patch fixes the solaris
usb lib build arguments and the variable settings in
./include/sane/config.h correctly.

it does add ax_path_generic.m4 and ax_compare_version.m4.

ax_path_generic.m4 is where the envvar LIBUSB_* are introduced
iirc, but the envvar name might not be fixed and could
be tweaked to match the sane-backends names USB_*.

[ do not right now recall why ax_compare_version.m4
  was needed; maybe needed by ax_path_generic.m4 ? ]

if these two additions are an objection i can see if there
is a way to do it with the autoconf stuff in accordance with
autoconf-2.69: 5.2.2 Generic Program and File Checks.

in fact, at first glance, AC_PATH_PROG does look to be
the solution.  naturally AC_PATH_PROG is not in calcotes'
autotools book index!  shoulda waited for the 2nd edition
due in sep 2019, but it will be out-of-date by then anyway.

let me dig deeper on this and get back to you with a
different configure.ac patch.

[it will take a while, but it is 'on-the-list']

aloha

ras

the following is 'out-of-band' commentary

second: yep!  my "odd-ball os" does indeed provide
a nearly 15 year old usb lib, then again the
entire "odd-ball os" is nearly that old too:
solaris 10 update 8 is dated oct 2009.
twok:(inet)-root 1313 $  libusb-config --version
0.1.7

yep! it is "old".  should i see if i could upgrade,
maybe; but recall that this is an "odd-ball os"
(e.g. bigendian, sparc, with a custom svr4-ish
kernel crafted by a company no longer in existence).
certainly not a platform (actively) supported by
the usblib build system.  further consider that
the usb stuff might be so inter-woven into the fabric
of the sun solaris kernel that the effort has
a high likelihood of failure.

now consider: is there any actual reason to upgrade?
the 0.1.7 libusb has all the functions needed for
sane-backends-1.0.27 (sane-backends-1.0.x with c++
'improvements' might be a different story), but
right now there isn't much that says an upgrade
is necessary, required or even worth while.

second part 2: why not upgrade to a newer or newest
solaris 10/11 for sparc.  well, i've looked over
the licensing associated licensing agreement(s)
and it looks to me that too do so would either
require buying annual renewal or some-such or
risk it and run illegally.  the first is out-of-budget,
the second is, well, illegal.  oracle seems
not to want to provide an allowance for non-commercial,
personal use like sun micro did.  [sol10u8 is the
last solaris release under the sun micro banner]

third: linux -- i'd like to upgrade, but i don't
have a lot of available $$$ to replace my old
legacy hardware.  then what hardware and which
of the dozens of linux do i select and why those
particular selections over the other dozens of
choices.  then consider the effort needed to tweak
all of my 20+ years of [ohmygod] csh scripts,
sun /bin/sh scripts, rebuild all custom c-src
utils/apps of my own design (hack might be more
appropriate) all the while having to migrating
from bigendian ufs to some other unknown to me
linux file-system.  then what about all the
incompatibility messages i see on most fossy
applications ...

it is enough to make me 'hang in there with my
old old old "odd-ball os" but static os' that
i have some arguably reasonable grasp upon.

dunno if i'm right, but the choice seems clear to me
'if it ain't broke don't fix it'.

third part 2: how about linux for sun4u sparc
hardware?  i've not found a release or even
a hint that such might be possible without
substantial additional effort.

Olaf Meeuwissen wrote:
> Hi ras,
> 
> r. a. schmied writes:
> 
> 
>>i've embedded some more text way down towards the bottom
>>regarding the AS_CASE(x$host_os,...) call and my solution
>>history as related to/with solaris 10 sparc and its libusb.
> 
> 
>>Olaf Meeuwissen wrote:
>>
>>>[...]
>>>By all means share your "hack".
> 
> 
> Thanks for sharing!
> 
> 
>>first off the AS_CASE(x$host_os,...) in configure.ac is
>>intentionally disabled because of the leading 'x' char;
>>as x$host_os is never going to match any $host_os variable.
>>at least that was what i found when i created a case for solaris*.
> 
> 
> My bad!  Thanks for pointing out this stupidity.  The 'x' is prefixed
> just in case $host_os is empty.  Of course, that should be taken into
> account in the globs.  :brown_bag: :face_palm:
> 
> 
>>what this 'disabling' does do is always forces the *) choice
>>which employs pkg-config to get the data for libusb.
> 
> 
> ACK and that was completely unintentional.  Fixed in f901462f.
> 
> 
>>so without the pkg-config pc file for libusb configure failed
>>UNLESS i pre-set USB_CFLAGS and USB_LIBS on configure environment.
>>then, because configure then found usb.h it went ahead and
>>set #define HAVE_LIBUSB 1
>>
>>i saw/see no way to force configure to define HAVE_LIBUSB_LEGACY
>>instead, short of re-working configure.ac as i have done.
> 
> 
> You mentioned the existence of a libusb-config utility.  It was at an
> odd-ball location in /usr/sfw/bin/ but if that directory is in your
> PATH, then you should use that to get the various variables, without
> setting any LIBUSB_* variables in your environment or on the
> command-line when running configure.
> 
> All you should do is make sure /usr/sfw/bin/ is in your PATH or perhaps
> tinker with AC_PATH_PROG to find it.
> 
> # See https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/autoconf.html#Generic-Programs
> 
> What does running libusb-config produce?  IIRC, there are flags to limit
> output to LIBS and CFLAGS needed during the build.  These are the ones
> you need to collect in the configure.ac code.  You also want to get the
> libusb version from libusb-config if possible to determine which of
> HAVE_LIBUSB and HAVE_LIBUSB_LEGACY to set to '1'.
> 
> # From your patch I gather your libusb is 0.1.7.  That is so old it's
> # not funny anymore, BTW.  Hmm, I just noticed that our legacy check
> # prefers >= 0.1.8 ... :thinking_face: ... over a 10+ year old libusb
> # version that you appear to be using.  The code comment about 10+ is
> # itself will be three years old next month, so 13+ years old libusb.
> 
> 
>>[...] you saners are going to make a relatively large delta to
>>configure and friends i figured i try to solve this solaris usblib
>>problem 'the autotools way'.
> 
> 
> :+1:
> 
> The autotools are a bit of a steep learning curve :unamused:
> 
> 
>>[...]
>>other things about autotools i've learned about the hard way:
>>for example the current configure setup uses envvars
>>USB_CFLAGS and USB_LIBS, but the ax_path_generic.m4 and
>>ax_compare_version.m4 use/create envvars LIBUSB_CFLAGS and
>>LIBUSB_LIBS.  that might be because i'm still a nooby with
>>autotools, but it still is a wrinkle that really should be
>>ironed out.  i'm sure there are others ....
> 
> 
> I'm fairly sure this is caused by differences between libusb-1.0 and
> libusb-0.1.  The former uses 'libusb' and 'LIBUSB', the latter uses
> versions without the 'lib'/'LIB' bits.
> 
> FWIW, the sane-backends prefer libusb-1.0.
> 
> 
>>[...]
> 
> 
> 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
> 