[sane-devel] minor: libusb not recognized

Enrico Weigelt weigelt@metux.de
Tue, 30 Mar 2004 21:31:49 +0000

* Henning Meier-Geinitz <henning@meier-geinitz.de> [2004-03-30 20:13:29 +0200]:

> 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.
well, than just autoconf - where's the difference ?! ;-)

> Do all bourne-shell "compatible" shells support these features? 

> Does it really matter how the code that is created by autoconf look like?
yes. there's almost no day where I'm not forced to look at some configure
script and fix some nasty stuff ...

autoconf produces really unmaintainable code.

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

Well, if we'd provide all these information, the package maintainers just 
have to select what modules + features they wanna have and let the machine
do all the rest of the work. The current way, where the maintainer has
to do very much things manually (i.e. selecting single files for packages,etc)
is just an enormous resource wastal.

If all packages would provide such machine readable build information, 
the job of the package maintainer itself would be (almost) obsolete ;-)

> > 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.
well, then a static linked lib ?
there's no real conceptional difference between dynamic and static linked
libraries - just quest of one setting ...

> > 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.
Well, perhaps some people do not want libusb, so it should be a optional
feature, but perhaps enabled per default.

btw: for each feature there should be an flag for explicitly enabling 
or disabling this, and also there should be a option for dumping the
active features and their dependencies. 

> > * 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. 
... like I already said .. better let the machine do it by itself.

> Also it only makes sense if every software use the same format?
Well, that's where I want to go to (I'm trying this in a dozen of projects)
But someone has to make the first step :)

> > > > btw: the current libusb is broken - it's libfiles' names are missing .so.
> > > 
> > > Which current libusb?
> > 0.1.8
> Ah, you are right. Strange.
it also produces a wrong libusb.la file, so building sane-backends makes
also trouble on compiling ...

 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact@metux.de
  cellphone: +49 174 7066481
   -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --