[Nut-upsdev] New default for SNMP and USB (and HAL) compilation

[Arnaud Quette]

Best wishes for the new year Peter, Charles and others

2006/12/28, Peter Selinger <selinger at mathstat.dal.ca>:
> Hi Arnaud,
>
> I have reworked autoconf to the point where it should work correctly
> with HAL, and also should by default compile all drivers whose
> prerequisites are met.
>
> Here are some more details and random thoughts.
>
> * drivers: by default, they are built if possible, but if some
>   prerequisites are missing then configure skips them without
>   complaining. A summary is printed at the end of ./configure.
>   Of course, the user can request specific things with the
>   corresponding --with option.
>
> * CGI scripts and the upsclient library: the default is still *not* to
>   build and install these, because I believe most average users don't
>   need them. However, it is now possible to say e.g. --with-cgi=auto
>   (or indeed --with-all=auto) if the user wants to build all that is
>   possible. Similarly, --without-all should build no drivers at all.
>
> * make distcheck now works, HAL and all.
>
> * 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.
>
> * 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.
>
> * I wonder what is the difference between --with/--without style
>   configure options and --enable/--disable style options. One is
>   supposed to be for "features" and the other for "packages" but in
>   practice I am not sure which is which or what the real difference
>   is. But if anyone knows better, please let me know.
>
> * HAL design. The HAL binaries don't seem to be drivers; they seem to
>   be clienty-servery type things. Perhaps these should live in a
>   different subdirectly? This would also make it slightly easier to
>   pass specific CFLAGS and LDFLAGS.

in fact, these are drivers, but the dstate layer is replaced by the
HAL equivalence.

> * 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?)

the problem here is that when a USB UPS is detected (the HAL support
is for the moment limited to such auto discoverable devices), the
matching driver is launched by the hald, with some specific context
vars.

I've also thought about the way you present above, but I still need
some more tests and integration to get more visibility on the best
solution.

> * I have written several local autoconf macros, which are located in
>   the m4/ directory, and documented in docs/macros.txt. This makes the
>   configure.in shorter, more uniform, and more maintainable, while
>   leaving some ugly details out of view. ./configure.in is now down to
>   763 lines from 1001.

thanks again for all your work.
I'll test it asap.

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/