> - Modify the configure.in (and generate a new ./configure) to check
> for the existence, version, and location of this external library
> (which I'm currently calling PTAL, for "Peripheral Transport
> Abstraction Library"). ./configure currently does something similar
> to check for GTK.
To check the existence, add 'AC_CHECK_LIB(<lib>, <function_needed>)'
and 'AC_CHECK_HEADERS(<libheader.h>)' in 'configure.in'. Update
'include/sane/config.h.in' with the new defines. Then run 'autoconf'
to make a new configure file.
To check the version, you can either check for two different functions
using 'AC_CHECK_FUNCS(<function>) after you checked for the library to
see which one of them are present, write your own test program to
compare the library version against the requred version, or write a
test program to return a header define and do the comparing in
configure.in. I suggest the first method.
> - If the library is not found, then build the HP SCL backend as usual
> to support the usual connection methods (SCSI, device, PIO). Disable
> the new HP DTF backend I'm working on to support the sheetfed
> OfficeJets and the LaserJet 1100A (which could be connected either
> to a LAN via an HP JetDirect external print server, or eventually to
> the parallel port on a workstation using a Linux kernel module).
Check for the define HAVE_LIB<lib> to include code requiring the
library.
> - If the library is found, then enable the DTF backend. Use the gcc
> -D switch to pass in an extra #define to the HP SCL backend that
> enables my added code that interfaces with PTAL to support the
> SCL-based flatbed HP OfficeJets. What should I call this #define?
> "PTAL"? Or "HAVE_PTAL"?
It will be called HAVE_LIBPTAL if the library is called libptal.a.
> - When building PTAL-enabled backends, as well as versions of Peter
> Kirchgessner's hpinq and hpscan utilities that I've hacked to
> support PTAL, either statically or dynamically link the PTAL
> library to the corresponding backend or executable. I imagine
> dynamic linking would be preferable, but isn't it unavailable on
> certain platforms?
> And what would happen if both the SCL and DTF backends were
> running at the same time (i.e. under saned)?
I'm not sure if I understand which problem you are describing here.
> (Does PTAL need to be thread-safe, even through AFAIK none of its
> intended clients will be multi-threaded?)
Why should it not be thread safe? All libraries should be thread
safe. :-) It is currently not a requirement for SANE.
> So are the above items all I need to do, or can somebody tell me
> what else I need to do?
If your backend source is one set of files which conditional compile,
the above should be work. If you have two set of backend files
producing two different backends, you will need to add things like
this to configure.in:
if test "${ac_cv_header_sys_socket_h}" = "no"; then
echo "disabling NET backend"
NET=
else
echo "enabling NET backend"
NET=net
fi
AC_SUBST(NET)
The 'test'-part is checkig for a specific header file. It can also
check for functions and libraries. The 'NET' keyword need to be in
backend/Makefile.in, with '@' around it to be substituted when the
backend is enabled.
-- ##> Petter Reinholdtsen <## | pere@td.org.uit.no-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Fri Mar 10 2000 - 17:55:57 PST