Command Substitution in AC_ARG_WITH Help Strings

[Keith Marshall]

Hello,

I would like to implement a configure option which would have the effect of

AC_DEFUN([MY_LANGUAGE_SET],
[AC_ARG_WITH([languages],
AS_HELP_STRING([--with-languages=LIST],
[install language files in LIST, a comma separated subset of '$1']),
[languages=$withval],
[languages=en])])

MY_LANGUAGE_SET([`cd lang; echo ?? | tr " " ,`])

and have the result of the command substitution

   `cd lang; echo ?? | tr " " ,`

appear in the `configure --help' output.

Unfortunately, the appropriate section of the `configure --help' output is 
generated from a `here' document fragment in `configure', which is emitted 
with shell substitution disabled; thus, instead of seeing the result of the 
command substitution, I simply see the verbatim text of the command itself, 
which is not particularly informative for the user :-(

A possible workaround would be to distribute `configure.ac' itself as a 
`here' document within a shell script, to be executed prior to `autoconf', 
(or even executing `autoconf' itself), to generate `configure.ac' "on the 
fly";  this could then embed the result of the command substitution into 
`configure.ac', so that the appropriately substituted text would appear in 
the `configure --help' output.

This workaround is not ideal, since it:

a) imposes a requirement on the package maintainer to run a non-standard 
script, to regenerate `configure.ac', each time the available language set is 
updated; (perhaps having the script generate `configure.ac', run `autoconf' 
to generate `configure', and subsequently delete `configure.ac' again would 
help to enforce this discipline -- the script then becomes the required 
mechanism for generating `configure').

b) sets the list of available languages to the content of the `lang' 
directory of the development tree, at the time when `configure.ac' was last 
regenerated, rather than the content of the source tree, at the time when the 
package is `configure'd for building, (although, with due diligence from the 
maintainer, these would hopefully be the same).

Given these limitations, can anyone suggest a better mechanism for achieving 
this objective?  If the use of such a script is the preferred option, is 
there any preferred naming convention for it?  (Would this fall within the 
typical scope of a `bootstrap' script, for example?)

TIA for any suggestions.

Best regards,
Keith.