GNU Autoconf provides three ways to pass information to the generated configure scripts; these are enable-style flags, with-style flags and command line variables. Despite each one is provided with a very concrete goal in mind, many people overloads their meaning. Their purpose is clearly described in the manual, which these people "forget" to read. (I know it's impossible to read everything one would like to... not an excuse in this case, I'd say.)
So let's see which is the real purpose of the above methods:
- Enable-style flags: these are provided for packages that have optional compile-time features. They are defined using the AC_ARG_ENABLE macro. An example could be a --enable-debug argument. Note how this could change the behavior of the current package only, without adding additional dependencies nor requirements.
- With-style flags: these are provided for packages that require, or can optionally use, other software packages that are already installed. They are defined using the AC_ARG_WITH macro. An example that you can see in many packages is --with-x, used to manually enable or disable X11 support. Note how X11 is always an external package, hence the use of a with-style argument.
- Command line variables: anything else you can't do with the previous arguments. They are defined using the AC_ARG_VAR variable and are passed to the configure script as normal arguments. Most configure scripts provide some default variables defined this way. E.g., CC, which could be used as: ./configure CC=gcc, not CC=gcc ./configure. Be aware that both will work, but the semantics are quite different; I encourage you to read the manual.
Now let's analyze a problem I fixed two months ago, in which I required to pass the configuration script some information. For some "strange" reason, the Boost package creates libraries with different names (in fact, different suffixes) depending on the system where they are built on. Due to this, Monotone failed to build under NetBSD (or even SuSE Linux because it didn't know it had to use a different suffix.
I tried to fix it in an automated way, but AFAICT, it's almost impossible (or, at the very least, very error prone). So I decided to do it manually by passing the required information (the suffix name) to the configure script. Some people may have used a with-style argument, say --with-boost-suffix=<string>, but that'd have been incorrect. Remember that these arguments are to enable or disable external dependencies, but in this case we are not doing that. An enable-style argument would have been equally incorrect.
So I had to add a command line (environment) variable, called BOOST_SUFFIX, which takes the appropriate string for the current build system. The result is that, when needed, you can call the configure script with an extra argument that specifies how the library is named. I.e., what I have to do ATM is: ./configure BOOST_SUFFIX=-gcc.
