Dynamically change "configure --help" string based on compiler

Question

This question is related to Help string variable substitution for “configure --help”. Our configure.ac has the following. IS_SUN_COMPILER works as expected.

IS_SUN_COMPILER=`echo $COMPILER_VERSION | $EGREP -i -c -E 'Sun C\+\+'`
...

if test "$IS_SUN_COMPILER" = "1"; then
   DEF_VALUE_TLS=no
   m4_define([HELP_STRING_TLS], [enable thread storage (default is no)])
else
   DEF_VALUE_TLS=yes
   m4_define([HELP_STRING_TLS], [enable thread storage (default is yes)])
fi

AC_ARG_ENABLE(tls,
   AS_HELP_STRING([--enable-tls], [HELP_STRING_TLS]),
   ac_enable_tls=$enableval,
   ac_enable_tls=$DEF_VALUE_TLS)
AM_CONDITIONAL(HAS_PTHREADS, test $ac_enable_tls = yes)

Testing on Linux and OS X are OK, and default is yes is displayed. When I test on Solaris with SunCC the default value is default is yes which is incorrect:

CXX=/opt/developerstudio12.6/bin/CC ./configure --help
...

  --enable-tls            enable thread storage (default is yes)

How do I dynamically change the default value and help string?

John Bollinger · Accepted Answer · 2018-07-30T17:18:28.077

How do I dynamically change the default value and help string?

Remember that configure --help outputs help text without running any (Autoconf) tests. Therefore, the help message cannot be varied based on the outcome of any such tests.

Remember also that m4 processing of the Autoconf input is insensitive to the actual text of the input, except for m4 operators and recognized macros. Therefore, you cannot use shell conditionals to influence m4's output. m4 does have its own set of built-in conditional macros, but of course these have their effect when you're building the configure script, not when you're running it.

Thus, given this code:

if test "$IS_SUN_COMPILER" = "1"; then
   DEF_VALUE_TLS=no
   m4_define([HELP_STRING_TLS], [enable thread storage (default is no)])
else
   DEF_VALUE_TLS=yes
   m4_define([HELP_STRING_TLS], [enable thread storage (default is yes)])
fi

, the macro HELP_STRING_TLS is first defined to "enable thread storage (default is no)", and then very quickly (and unconditionally) redefined to "enable thread storage (default is yes)" before it is ever expanded. The shell if construct is just text to m4.

I suggest you proceed by making the help text more generic. The fact is that the default value for your enable-tls option depends on the compiler used, so just say that. Remember the user's choice, if any, and apply it later, after the compiler has been determined. Maybe something like this:

AC_ARG_ENABLE([tls],
  AS_HELP_STRING([--enable-tls],
    [enable thread-local storage (default is compiler-dependent)]),
  [], [enable_tls=""]
)
# note: you get shell variable $enable_tls for free when the --enable or
# --disable option is given; no need to create another variable

# ...

AS_IF([test "x$enable_tls" = x], [
  AS_IF([test "$IS_SUN_COMPILER" = "1"], [
    enable_tls=no
  ], [
    enable_tls=yes
  ]
])

AM_CONDITIONAL([HAS_PTHREADS], [test "$enable_tls" = yes])

The accompanying documentation can explain the compiler dependency of this option's default value at whatever level of detail you think is appropriate. Users who actually care about whether TLS is used will be obligated either to read and understand the docs, or else simply to give the appropriate option as if there were no default. Users who don't care specifically about it get whatever behavior is the default for the chosen compiler.

A couple of other comments: I urge you to avoid defining shell variables with an ac_ name prefix. Such names are reserved for Autoconf.
It smells a bit fishy to me that you're using "enable tls" to determine the value of an Automake conditional named HAS_PTHREADS. If this is really a user-selectable option, at least for some compilers, then I'd name the conditional USE_PTHREADS, instead, and probably name the option --enable-pthreads.

Thanks John. I think the wrong default setting with a generic message is a bad strategy. It is 2018 and we prefer to do the extra work instead of pushing it onto the users. We certainly don't expect users to RTFM. We feel requiring a user to read a manual is a design failure, which makes it our bug. This stuff should be easy to use correctly out of the box. — jww, Jul 30 '18 at 18:37
Regarding the variable names, what does Autconf use for `--with-XXX` or `--enable-XXX`? We were trying to seamlessly integrate with Autoconf, including variables. The Autoconf manual did not discuss the topic at [Choosing Package Options](http://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Package-Options.html). (And it lacked examples. That is one of my biggest complaints with the docs. There are little to no examples so we have to go searching on the web once we read about something. I'm sure we are picking up a lot of worse practices due to lack of official examples). — jww, Jul 30 '18 at 18:38
Who said anything about a *wrong* default setting, @jww? I suggested that if the user does not specify, then they get default behavior appropriate to their compiler. If there's only one right choice then why are you offering an option at all? — John Bollinger, Jul 30 '18 at 18:41
As for variable names, I take you to be asking about the variables set with the values of `--enable` or `--with` options, such as the `$enable_tls` I suggested using. These are described in the documentation of the `AC_ARG_ENABLE` and `AC_ARG_WITH` macros, which is also the context in which they are most often used. They are `$enable_XXX` and `$with_XXX`, respectively, with any non-alphanumeric characters in the XXX converted to underscores (`_`). — John Bollinger, Jul 30 '18 at 18:57

Dynamically change "configure --help" string based on compiler

1 Answers1