[BRLTTY] A nit about aclocal.m4

Stepan Kasal kasal at ucw.cz
Tue Sep 4 09:00:52 EDT 2007


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


More information about the BRLTTY mailing list