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. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
