[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