[sane-devel] Proposal to remove autoconf-generated files from the source repository
r. a. schmied
uwppp at flash.net
Wed Jun 19 15:47:45 BST 2019
olaf interested saners
specifically regarding the sun solaris /usr/sfw/bin/usblib-config
and how to check for it and use it ...
the two autotools m4 files m4/ax_compare_version.m4 and
m4/ax_path_generic.m4 looked to me (a complete autotool
novice) a standardish way to find and run a generic
*-config util script/program.
this these one can optionally set
to force configure to use that particular one.
and of course LIBUSB_LIBS and LIBUSB_CFLAGS.
twok:(inet)-root 1312 $ libusb-config --help
Usage: libusb-config [OPTIONS] [LIBRARIES]
i could have forced the issue in the solaris*) case
and run /usr/sfw/bin/usblib-config directly to get
and set the needed USB_* envvars, but that did not
(does not) appear to be the 'autotools way' even for
an "odd-ball operating system", but i'm ok with that
solution if you all are.
but with that said i will proceed to read the remainder
of your note and study the referenced url on #generic-programs,
think i must have already looked at that because i do
recall reading extensively about autotools/autoconf,
but very possibly i missed the autoconf manual. there
seems to be a lot of autotools documentation available but
nothing (very little) that really gives a top-level
here's the way to use it overview with an example of
something more complex than "hello_world.c", well save
for calcote's autotools. so armed i might find
i) a better way if this initial suggested
configure.ac meets resistance
ii) further enhance the solaris*) case to include
compile and link trys
iii) anything else the sane-backenders insist on
probably more on this later ...
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