[sane-devel] minor: libusb not recognized

[Henning Meier-Geinitz]

Hi,

On Tue, Mar 30, 2004 at 07:41:46PM +0000, Enrico Weigelt wrote:
> it is generally a bad idea if the user has no control over the build process.
> perhaps for self-compiling users it doesn't matter very much, but for 
> packaging it's really essential to know exactly what gets in and what 
> comes out of the build process.

Ok.

> <snip>
> > > better introduce a --enable-libusb configure option, which will check for 
> > > libusb and aborts with an error message when libusb is not found.
> > 
> > As an optional feature, this may be useful. But by default, the
> > current behaviour should stay the same IMHO.
> > 
> > Please send a patch.
> I'm not familar w/ automake, so where should I look at ?

Not at automake as we don't use automake :-)

We only use autoconf (and autoheader, aclocal) to generate configure
from configure.in and acinclude.m4 and to generate
include/sane/config.h forom config.h.in.

> When I look at the configure scripts, I can't get away from the idea that
> writing it by hand would be a better than using automake ...
> (why can't it simply use such trivial things like functions and includes ?!)

Do all bourne-shell "compatible" shells support these features? Does
it really matter how the code that is created by autoconf look like?
In configure.in (or acinclude.m4) you can use functions if you like.

> well, I'd like to have a simple (machine readable) file, which exactly 
> describes what modules can be built from the package, which optional 
> features the may have and what dependencies they all have.

I see. In my opinion that's job for package maintainers. While we could
provide some hooks (like --without-frontends --without-tools) I think
the details are really up to the different package maintainers.

> those backends which 're using libusb then provide the optional feature
> "use-libusb" (or perhaps some better name...). if the usb access code  
> of these backends resides in a common lib,

It's a common part of code but that part is linked into the backends
themselves. No extra usb lib.

> then just this lib would provide
> this feature. in the documentation we'd give a note, that linux-2.6-users
> should try this feature if they dont have /dev/usbscanner (it seems that
> 2.6 doesnt have usb scanner drivers anylonger)

It's true that Linux 2.6 doesn't have a kernel scanner driver any more.
As some features don't work with the kernel scanner driver anyway,
there is no reason to not use libusb on every system in my opinion.
There is even one backend (sm3600) which doesn't work at all without
libusb.

> at the end we'll have a build system, which allows us to:
> 
> * list all modules in a package, their features and all their dependencies
> * build a list of modules w/ specified features
>   (also support for chroot-builds + crosscompile)
> * spit out a list of files and their classes for each module

Looks like package maintainer's stuff for me. Also it only makes sense
if every software use the same format?

> * install evryting into some prefix

That should already work with the current build system.

> > > btw: the current libusb is broken - it's libfiles' names are missing .so.
> > 
> > Which current libusb?
> 0.1.8

Ah, you are right. Strange.

Bye,
  Henning