On Mon, May 26, 2025 at 10:39:13AM +0200, R. Diez wrote:
> 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])
> ]
> )
Like with AS_IF, AS_CASE is not an m4 conditional. All the "branches"
are expanded and included in the configure output, so all of these
m4_defines are expanded unconditionally. For macros defined multiple
times, a later definitions will supersede an earlier one, so you
end up with one (probably TODO for both).
> I am guessing there is no way around this, is there?
Even if there was a way to expand shell variables in the --help text,
you wouldn't be able to easily use $host_cpu because this requires
running actual configure tests to determine (via AC_CANONICAL_HOST).
None of this is performed for ./configure --help which exits configure
right after option parsing.
> > 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.
I think for this something like
"default: depends on cpu type"
is totally acceptable for a --help brief. If it matters, you can go
into as much detail as you like in the manual.
> 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.
I think users who take the time to read documentation are likely going
to understand that if the description of an option suggests the default
varies, they should specify the option if they care about it one way or
the other.
You don't need to worry about users who don't read the documentation,
as it makes no difference what you write in this case.
Cheers,
Nick
