| Summary: | [PATCH] configure.in broken acpi options | ||
|---|---|---|---|
| Product: | hal | Reporter: | Michael Burns <mburns> |
| Component: | build | Assignee: | Danny Kukawka <danny.kukawka> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | Keywords: | patch |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Patch for configure.in to fix acpi configure options | ||
Created attachment 5987 [details] [review] Patch for configure.in to fix acpi configure options patch against latest CVS configure.in Commited slightly changed: commit 275f3346f334b62181ece389d7118c7dc1422c83 Author: Michael Burns <mburns@cs.princeton.edu> Date: Fri Sep 1 14:48:11 2006 +0200 fix ACPI acpid/proc configure options Fix for fd.o bug 7278. From Bugzilla: "... HAL 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." NOTE: You maybe need to check and adapt your current configure options for the ACPI settings. The behavior maybe differ from the current. see last comment ... fixed now. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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