[sane-devel] Proposal to remove autoconf-generated files from the source repository
r. a. schmied
uwppp at flash.net
Wed Jun 19 17:31:52 BST 2019
olaf interested saners
> The autotools are a bit of a steep learning curve :unamused:
first: the submitted configure.ac patch fixes the solaris
usb lib build arguments and the variable settings in
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']
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
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
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'.
> 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
More information about the sane-devel