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

[r. a. schmied]

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
LIBUSB_CONFIG=<absolute_path>
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]
Options:
        [--prefix[=DIR]]
        [--exec-prefix[=DIR]]
        [--version]
        [--libs]
        [--cflags]


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

aloha

ras



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
>