Hello Dave,
I noticed that your aclocal.m4 conatains a macro
AC_DEFUN([BRLTTY_ARG_FEATURE], [dnl
AC_ARG_ENABLE([$1], BRLTTY_HELP_STRING([--$3-$1], [$2]), [], [enableval="$4"])
...
something with $enableval
...
])
I'd like to remind that the main variable used by
AC_ARG_ENABLE([foo], ... )
is enable_foo. The variable `enableval' is only a helper variable
guranteed to be available for the code in the third parameter.
IOW, AC_ARG_ENABLE([foo], help-text, code-if-given, code-if-not)
expands to something like this:
if ``enable_foo is set''; then
enableval=$enable_foo
code-if-given
else
code-if-not
fi
This means that `enableval' is kind-of-reserved for Autoconf. The
code mentioned above leaves `enableval' available after the macro,
but I would not rely on that.
So the beginning of BRLTTY_ARG_FEATURE would be safer if written this
way:
AC_ARG_ENABLE([$1], BRLTTY_HELP_STRING([--$3-$1], [$2]), [],
[enable_[]m4_translit([$1], -, _)="$4"])
enableval=$enable_[]m4_translit([$1], -, _)
...
Well, BRLTTY_ARG_FEATURE then continues by defining
brltty_enabled_[]m4_translit([$1], -, _)
Perhaps that overlap could be cleaned up somehow.
I do not offer a patch. One of the reasons is that I think that my
solution may not correspond with your idea of clean and readable
code. Does this make sense?
Have a nice day,
Stepan Kasal
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
