First of all, thanks for your help.
M4 macros are fine but as documented, AS_HELP_STRING does not expand its
second argument, so you need to be careful about quoting when you use it.
[...]
If the defaults can be determined by m4 then you can use m4 to generate
the help string.
[...]
All the help text is generated statically at m4 time and is included
into the configure script as a quoted here-document. So the shell will
not expand anything found within the help text at configure time.
I think that is the root of the problem. The default comes from variable
${host_cpu}, which cannot be determined by m4 alone when generating the
configure script.
To illustrate it, this is a piece of code I tried, which did not work either:
AS_CASE(["${host_cpu}"],
[arm*], [
m4_define([host_arm_bitbang_adapters_default], [auto])
m4_define([host_arm_or_aarch64_bitbang_adapters_default], [auto])
],
[aarch64], [
m4_define([host_arm_or_aarch64_bitbang_adapters_default], [auto])
],
[
m4_define([host_arm_bitbang_adapters_default], [TODO])
m4_define([host_arm_or_aarch64_bitbang_adapters_default], [TODO])
]
)
I am guessing there is no way around this, is there?
Otherwise, just write some text which is vague about the default.
Something like "default: auto" is usually fine.
The trouble is, OpenOCD uses "auto" with the following meaning: if the right libraries etc. are
installed, enable the option. That is, enable the option if compilation should succeed. I would have to
rewrite a chunk of configure.ac to provide a different "vague" help text for these options alone,
and to implement the meaning of "auto" differently for those options.
Furthermore, I don't like the idea of being vague. It is then hard to predict
whether a particular option would be automatically enabled, and that opens a
window for head scratching, or perhaps I should write yet more custom
configure.ac code for these options.
But I guess I am out of options. I'll speak to the OpenOCD guys about this.
Thanks again,
rdiez
