The current version of hal (0.5.7) as well as that in CVS contains a flawed
configure.in that disables acpi-proc support when --enable-acpi-proc is passed
as an argument. --disable-acpi-proc correctly disables it, and not specifying
anything correctly enables it. This is because the current code does not check
the $enableval as it should. The acpi-acpid enable flag is similarly broken.
This causes acpi support to be disabled for distributions that attempt to enable
it via --enable-acpi-*. I've attached a patch for the configure.in from CVS HEAD
which should fix the problem, allowing enable-acpi-* and disable-acpi-* to be
correctly detected and enabled by default.

--- configure.in_old	2006-06-20 01:00:35.000000000 -0400
+++ configure.in	2006-06-20 01:04:29.000000000 -0400
@@ -81,14 +81,22 @@
 GTK_DOC_CHECK([1.3])
 
 # ACPI event source
-AC_ARG_ENABLE(acpi-acpid, [  --disable-acpi-acpid    do not use acpid event
source],acpi_acpid=no,acpi_acpid=yes)
+AC_ARG_ENABLE([acpi-acpid],
+              AC_HELP_STRING([--disable-acpi-acpid],
+                             [Do not use ACPI daemon event source]),
+              [acpi_acpid=$enableval],
+              [acpi_acpid=yes])
 if test "x$acpi_acpid" == "xyes" ; then
    AC_DEFINE(ACPI_ACPID,1,[Common event source of ACPI events])
 fi
 AC_SUBST(ACPI_ACPID)
 AM_CONDITIONAL(ACPI_ACPID, test x$acpi_acpid != xyes)
 
-AC_ARG_ENABLE(acpi-proc, [  --disable-acpi-proc     do not use acpi kernel
interface directly],acpi_proc=no,acpi_proc=yes)
+AC_ARG_ENABLE([acpi-proc],
+              AC_HELP_STRING([--disable-acpi-proc],
+                             [Do not use ACPI kernel-interface directly (the
kernel supports only one listener)]),
+              [acpi_proc=$enableval],
+              [acpi_proc=yes])
 if test "x$acpi_proc" == "xyes" ; then
    AC_DEFINE(ACPI_PROC,1,[Direct kernel connection for ACPI events, the kernel
interface is exclusive to one user only])
 fi