[Nut-upsdev] New default for SNMP and USB (and HAL) compilation
Charles Lepple
clepple at gmail.com
Fri Dec 29 02:05:58 CET 2006
On 12/28/06, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> * make distcheck now works, HAL and all.
Hmm, 'make distcheck' now fails for me on OS X because I don't have
hiddev. It will probably fail later because I don't have HAL. Could we
have distcheck use '--with-all=auto' instead? I realize this makes
distcheck slightly less all-encompassing, but that would make it
useful on platforms other than Linux.
> * the checks for libusb, libhal, and libnetsnmp are performed even if
> the corresponding --without options are given. This is because we
> have no good way of checking which drivers the user selected with
> --with-drivers=xxx,yyy,zzz, and these drivers might need the
> libraries.
With SVN rev 658, "--with-hal=no" doesn't seem to prevent the system
from building main-hal.c:
checking for libhal cflags via pkg-config... not found
checking for libhal ldflags via pkg-config... not found
checking libhal.h usability... no
checking libhal.h presence... no
checking for libhal.h... no
checking for libhal_ctx_init in -lhal... no
[...]
checking whether to enable HAL support... no
[...]
if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include
-DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -O -Wall
-Wsign-compare -MT libnuthalmain_a-main-hal.o -MD -MP -MF
".deps/libnuthalmain_a-main-hal.Tpo" -c -o libnuthalmain_a-main-hal.o
`test -f 'main-hal.c' || echo './'`main-hal.c; \
then mv -f ".deps/libnuthalmain_a-main-hal.Tpo"
".deps/libnuthalmain_a-main-hal.Po"; else rm -f
".deps/libnuthalmain_a-main-hal.Tpo"; exit 1; fi
main-hal.c:24:24: error: hal/libhal.h: No such file or directory
main-hal.c:27: error: parse error before '*' token
> * Charles, you made some autoconf changes in your man branch, which
> probably should have gone in the trunk. I believe I have now made
> equivalent changes in the trunk, so be careful when merging.
Thanks for the heads-up. I knew I was going to be away for a few days,
so I didn't want to mess up the trunk and leave.
The man page changes will be merged in to the trunk soon. (I guess I
didn't need to be so cautious with the branch since 2.0.5 is being cut
from branches/Testing.) I would like to solve the HAL problem first,
though, so that I know I am not introducing any regressions if things
don't merge cleanly.
> * HAL design. Is it necessary to create a dedicated HAL clone for each
> existing driver? Would it not be better to take advantage of the
> already existing modular approach, and have a single HAL application
> that will select the desired NUT driver, start it as a child
> process, and communicate with it through its socket (without using
> upsd as I understand?)
I vaguely recall Arnaud mentioning that the current implementation was
just a temporary hack, but you're right, it would be better for the
HAL interface to either use libupsclient or act as a surrogate upsd.
--
- Charles Lepple
More information about the Nut-upsdev
mailing list