[Bro] Bro & Autoconf 2.62

Christian Kreibich christian at whoop.org
Fri Aug 29 04:06:32 PDT 2008

Hi Stepan,

On Fri, 2008-08-29 at 12:37 +0200, Stepan Kasal wrote:
> Hello Christian and Vern,
> > Thanks -- the patch seems to do a little more than just rename a
> > colliding variable (which I presume was "simplified").
> Actually, it's not the case.  I have bundled two changes into the
> patch, without proper explanation; I'm sorry for that.
> The problem was that configure built with Autoconf 2.62 died
> conpaining that unknown option "option-checking" was used.
> The problem is that with Autoconf 2.62, shell variable
> enable_option_checking is set near the top of the script, no matter
> whether --enable-option-checking was given or not.
> When your macro AC_LBL_ENABLE_CHECK finds this variable in the
> environment, it bails out compaining about unknown option named
> "option_checking".  That makes the configuire script unusable.

Ah! That rings a bell, but I can't seem to remember the circumstances
under which this was pointed out to us in the past. I'm sure though that
it was, and in fact we were considering ditching the (dated)
AC_LBL_ENABLE_CHECK in favor of the new built-in option checking once
2.62 is in widespread use.

> The issue can be fixed by this change:
> --- bro-20080804/acinclude.m4.orig	2006-04-23 07:55:10.000000000 +0200
> +++ bro-20080804/acinclude.m4	2008-08-26 16:19:45.000000000 +0200
> @@ -192,7 +192,7 @@
>  	    ok=0
>          dnl change '-' to '_' 
>          simplified=`echo $1| sed -e 's/-/_/g'`
> -        for o in $simplified; do
> +        for o in option_checking $simplified; do
>  		    if test "${o}" = "${var}" ; then
>  			    ok=1
>  			    break
> This way, the built in enable_option_checking option is added to the
> list of options supplied as a parameter to AC_LBL_ENABLE_CHECK.

Understood, and agreed with.

> > I like the use of
> > m4_translit, assuming it is provided by a wide range of m4 versions.
> That was the other change; I thought the substitution should rather
> be done when configure is created, not during its run. And yes,
> m4_translit is available for very long time, no problem.

Okay, likewise agreed with then.

> Yes, Autoconf 2.62 introduces option checking (for both --enable-* and
> --with-* options).  Unfortunately, this feature is not generally
> compatible with recursive configure calls, at least in its present
> form, so it's switched on by default as soon as AC_CONFIG_SUBDIRS is
> used.  You could run configure with --enable-option-checking, but you
> would get many false warnings from the sub configures.

Got it.

> Let me remind: AC_CONFIG_SUBDIRS is not primarily meant to define a
> structure within a huge project, it is meant for incorporating
> tarballs, which are not under your control.  The tarballs are
> generally supposed to have different maintainers, the configure
> scripts might be generated by different version of Autoconf, etc.

We're aware of that. We needed a way to combine individual subtrees into
a single tree so that the overall tree would "just build", while
preserving the ability to produce tarballs of the subtrees when needed.

> You might file a feature request to enhance the
> --enable-option-checking so that it supports sub-configures, to
> bug-autoconf at gnu.org.
> Or, if the sub-projects are maintained more or less together with the
> main project, you might integrate them so that they use a tree of
> Makefiles, but one common configure script.  I would be glad to help
> you investigate this possibility, but for general good, we should
> move to autoconf at gnu.org with that.

Regarding this, see my point above -- we primarily want a tree that
builds from scratch, but can provide subtree tarballs when needed.
Advice on how to do this, assuming our current approach is horribly
wrong, would be appreciated, but the real problem for us is lack of time
for a much-needed overhaul of our build scripts.

> Hope this mail helps.  I hope I managed to keep the offense rate low.
> ;-)

I'll be the last person to claim that our autotools setup is in good
shape at this point, so don't worry about offenses. :^)


More information about the Bro mailing list