[sane-devel] Re: Problem to make with the 2001-09-15 tgz

[Henning Meier-Geinitz]

Hi,

On Tue, Sep 18, 2001 at 09:24:31PM -0600, Marcio Luis Teixeira wrote:
> The truth is, the Makefile probably has a lot of problems. The gotcha
> is that I derived my Makefile from the SANE distribution's Makefile,
> by deleting the names of all the other backends, and keeping only the
> stuff related to the umax1220u backend.
> 
> This is sloppy, because the Makefile for SANE is created by the
> "./configure" script and is tailored to each system it runs on. By basing
> *my* Makefile on that one, I ended up with a Makefile that only works
> on my system (or very similar ones).
> 
> In short, it's a pretty lousy Makefile, but I don't have anything better
> right now.

I didn't look at your Makefile, but can't you just use the Makefile.in
from SANE and remove the parts you don't need? Then let the user
create a new Makefile by running ./configure. So Everything is set
automatically. This is how I do it with the mustek_usb backend: The
user gets sane-backends-1.0.5.tar.gz, untars it, untars
mustek_usb-backend.tar.gz in the same directory (which contains the
backend and modified Makefile.ins in backend/ and doc/), calls
configure, make and make install as usual.

> What I think would be really handy would be if the SANE distribution
> included a cannonical Makefile that could be used when developing
> other backends. Maybe it could even include a sort of backend SDK
> that developers could use as a starting point for their projects. Something
> like a single self-contained subdirectory with a sample backend (such
> as the pnm backend) and a Makefile that built and installed only that
> backend.

I don't think that this is necessary. The whole goal is to keep one
directory and one Makefile. If you really don't want to compile the
other backends (e.g. for compilation time reasons), disable them by
removing them from the PRELOADABLE_BACKENDS variable.

> > While I'm at it I have a couple other dumb questions: I am not familiar at
> > all with that region of the kernel (although I somewhat play with the
> > networking stack once in a while) but, why do you need to uncomment that:
> > #define SCN_IOCTL
> >
> > In the 2.4.5 kernel that come with Mandrake 8.0 Freq, the comment above that
> > line says:
> > /* Enable to activate the ioctl interface.  This is mainly meant for */
> > /* development purposes until an ioctl number is officially registered */
> >
> > Why don't you ask for an officially registered ioctl number ?  It is not such
> > a scarce ressource, and it would save all your user the lenghty process of
> > rebuilding their kernel (and breaking their distro :-(
> 
> I would love to be able to fix this more formally, but the short answer is, I
> don't
> know who to ask.

Probably the developer of the kernel scanner module,  David E. Nelson
(dnelson at jump.net) or the kernel mailing list.

> In the future, there may even be ways around this altogether.
> I know there was some discussion on the list about standardizing the USB
> interface in SANE. If this happens, that SCN_IOCTL may not even be
> necessary.

The sanei_usb file is there. It supports (as far as I know) everything
the Linux kernel supports out of the box. It's possible to add other
things than the bulk transfers but this won't help until this is
supported by standard kernels. I won't do it because my scanners don't
need it, so it's up to someone who needs it and can test it.

> > Last stupid question, somewhere else in your install page you say:
> > 3) Create a device file for /dev/usbscanner
> >
> >    (must be done from root!)
> >
> >    mknod /dev/usbscanner c 180 48
> >    chmod a+rw /dev/usbscanner
> >
> > My distro come with a  c 180 48 device file called /dev/usb/scanner0. (and
> > all other up to scanner 15 using minor 63. Do I really need to use the
> > /dev/usbscanner name ?  What about a ln -s to /dev/usb/scanner ?  And what if
> > I was using devfs ?
> 
> As far as I know, creating another device file with the same numbers should not
> harm anything. It would effectively be an alias for the device.
> 
> Ideally, I suppose my backend should be made configurable, so you could tell
> it what device file to use, but it's not at that point yet (right now, I'm glad
> I have
> something that works! :)

It shouldn't be too complicated to copy the code for reading the
config files from e.g. mustek_usb.c. Hey, this is open source :-)

Bye,
  Henning