Project

General

Profile

Actions
Copy link

Bug #1835

closed
DW

AC_ARG_ENABLE usage is incorrect

Bug #1835: AC_ARG_ENABLE usage is incorrect

Added by Daniel Weeks almost 10 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

Description

In several locations in configure.ac the AC_ARG_ENABLE usage is incorrect or at least non-standard. Whether --enable-<feature> or --disable-<feature> flag is passed to configure it is treated as if the feature is enabled. The only way to disable a feature is to not pass either option to configure. A user that explicitly disables a feature because a dependency is not available will be met with a unexpected error.

Related issues 3 (0 open — 3 closed)

Related to Suricata - Bug #2468: The autoconf process fails when some options are disabledClosedActions
Related to Suricata - Bug #2473: Please allow disabling every option (add --without-{option})ClosedActions
Is duplicate of Suricata - Bug #2797: configure.ac: broken --{enable,disable}-xxx optionsClosedFabrice FontaineActions

VJ Updated by Victor Julien almost 10 years ago Actions
Copy link
 #1

Can you be more specific about which ones are incorrect?

AH Updated by Andreas Herz almost 10 years ago Actions
Copy link
 #2

  • Tracker changed from Bug to Optimization
  • Assignee set to Andreas Herz
  • Target version set to TBD

We will try to improve the whole configure.ac file to be more consistent so we can address that within the general rework. But yes, please provide more details so we can take that into account :)

DW Updated by Daniel Weeks almost 10 years ago Actions
Copy link
 #3

I originally discovered it in the hiredis option but I can see at a glance the same structure exists with the nflog, nfqueue, dag, napatech, and lua options. It appears the form assumed in configure.ac is AC_ARG_ENABLE(..., [action-if-disabled], [action-if-enabled]) when in fact it is AC_ARG_ENABLE(..., [action-if-given], [action-if-not-given]). This leads to configure checking for libraries after the feature has been disabled because /some/ option has been supplied.

Also, in my opinion, this is a clear bug, not an optimization. When a user explicitly sets a feature to be disabled, they expect that to be honored. It is not in these cases.

VJ Updated by Victor Julien about 9 years ago Actions
Copy link
 #4

  • Tracker changed from Optimization to Bug
  • Status changed from New to Assigned
  • Priority changed from Normal to High
  • Target version changed from TBD to 70

VJ Updated by Victor Julien about 8 years ago Actions
Copy link
 #5

  • Related to Bug #2468: The autoconf process fails when some options are disabled added

VJ Updated by Victor Julien about 8 years ago Actions
Copy link
 #6

  • Related to Bug #2473: Please allow disabling every option (add --without-{option}) added

VJ Updated by Victor Julien about 7 years ago Actions
Copy link
 #7

  • Is duplicate of Bug #2797: configure.ac: broken --{enable,disable}-xxx options added

VJ Updated by Victor Julien about 7 years ago Actions
Copy link
 #8

  • Status changed from Assigned to Closed
  • Assignee deleted (Andreas Herz)
  • Priority changed from High to Normal
  • Target version deleted (70)

Fixed in #2797

Actions
Copy link

Also available in: PDF Atom