Nut upsdev - Dec 2006 - New default for SNMP and USB (and HAL) compilation

fellows,

I'm working on integrating the preliminary HAL support, and thought a
bit about the default configure values below:
  --with-snmp             build and install SNMP drivers (no)
  --with-usb              build and install USB drivers (no)
[  --with-hal              build and install HAL support (no) ]

I wonder if some auto detection magic (if the requirement is present
enable the feature) wouldn't be better, allowing user to bypass this
using --with-feature=no

Notes:
- that this might be broaden to all "--with-feature"
- a feature synthesis might also be interesting at the end of the
configure run, to easily check what is enabled or disabled.

any thought?

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/

On Thu, 21 Dec 2006, Arnaud Quette wrote:
> fellows,
>
> I'm working on integrating the preliminary HAL support, and thought a
> bit about the default configure values below:
> --with-snmp             build and install SNMP drivers (no)
> --with-usb              build and install USB drivers (no)
> [  --with-hal              build and install HAL support (no) ]
>
> I wonder if some auto detection magic (if the requirement is present
> enable the feature) wouldn't be better, allowing user to bypass this
> using --with-feature=no
>
> Notes:
> - that this might be broaden to all "--with-feature"
> - a feature synthesis might also be interesting at the end of the
> configure run, to easily check what is enabled or disabled.
>
> any thought?
Sounds like a good idea to me, in general you tend to expect configure 
to detect the fact that you have the relevant devel stuff installed 
for feature X. Having to provide endles occurances of --with-foo is 
annoying.

/Nikke
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  Keptin, it's an inwisible moderator decloaking...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

On 12/21/06, Arnaud Quette <aquette.dev@gmail.com>
wrote:
> - a feature synthesis might also be interesting at the end of the
> configure run, to easily check what is enabled or disabled.
I agree with this one - witness my confusion with the libusb switches
several weeks ago :-)

I might have time to work on this over the next week or two. Let me
know if you (or anyone else) have already started on the feature
summary.

-- 
- Charles Lepple

I agree that this is a good idea. The reason I did not do this
immediately when converting to Automake is that I tried to be as
backward compatible as possible. In general, if --with-feature is not
given, then the prerequisite should be checked, and the feature
enabled if they are present. If --with-feature is given, then the
prerequisites should be checked, and the configure script should fail
if sthey are not present. If --without-feature is given, then the
prerequisites should not be checked at all (to save time).

To keep the logic short and maintainable, AC_ARG_WITH should just set
a variable, rather than performing all the checks. I.e., instead of

AC_MSG_CHECKING(whether to enable SSL development code)
AC_ARG_WITH(ssl,
AC_HELP_STRING(...),
[       case "$withval" in
        yes)
                AC_MSG_RESULT(yes)

                /* run checks */

                AC_DEFINE(HAVE_SSL, 1,
                        [Define to enable SSL development code])
                ;;
        *)
                AC_MSG_RESULT(no)
                ;;
        esac],

	/* run checks */

        AC_MSG_RESULT(...)
)

where we have to do the checks in 2 places, we should use something
like the following:

AC_ARG_WITH(ssl,
AC_HELP_STRING(...),
[       case "$withval" in
        yes)
                nut_with_ssl="yes"
                ;;
        *)
                nut_with_ssl="no"
                ;;
        esac],
        nut_with_ssl="auto"
)

if test "${nut_with_ssl}" != "no"; then
   AC_MSG_CHECKING(for SSL library availability)

   /* run checks */

   AC_MSG_RESULT([${ssl_ok}])
fi

if test "${nut_with_ssl}" = "yes" -a "${ssl_ok}" =
"no"; then
   AC_MSG_ERROR(["SSL support requested, but OpenSSL not found"])
fi

if test "${nut_with_ssl}" = "auto"; then
   nut_with_ssl="${ssl_ok}"
fi

AC_MSG_CHECKING(whether to enable SSL development code)
if test "${nut_with_ssl}" = "yes"; then
   AC_MSG_RESULT(yes)
   AC_DEFINE(HAVE_SSL, 1, [Define to enable SSL development code])
else
   AC_MSG_RESULT(no)
fi

If you want, I'll look into it. -- Peter

Arnaud Quette wrote:
> 
> fellows,
> 
> I'm working on integrating the preliminary HAL support, and thought a
> bit about the default configure values below:
>   --with-snmp             build and install SNMP drivers (no)
>   --with-usb              build and install USB drivers (no)
> [  --with-hal              build and install HAL support (no) ]
> 
> I wonder if some auto detection magic (if the requirement is present
> enable the feature) wouldn't be better, allowing user to bypass this
> using --with-feature=no
> 
> Notes:
> - that this might be broaden to all "--with-feature"
> - a feature synthesis might also be interesting at the end of the
> configure run, to easily check what is enabled or disabled.
> 
> any thought?
> 
> 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/
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>