Hi,
I encountered a problem with Autoconf during packaging Bro (svn rev.
6043) for Fedora 10 and after consulting it with Stepan Kasal he
created the attached patch that fixes this problem. It was caused by a
collision with the internal variable in Autoconf 2.62.
Dan
bro-20080804-configure-opt-check.patch (580 Bytes)
Hi Dan,
Hi,
I encountered a problem with Autoconf during packaging Bro (svn rev.
6043) for Fedora 10
Cool. (The packaging, not the encounter. 
May I ask what is your
strategy for the packaging? Ideally there'd be three separate RPMs for
Bro, Broccoli, and BinPAC, since they all serve different purposes and
just happen to live in a single tree (this has caused config headaches
more than once). Broccoli has a spec file, but I haven't touched it in a
while. The BinPAC tree at least has its own configure setup.
and after consulting it with Stepan Kasal he
created the attached patch that fixes this problem. It was caused by a
collision with the internal variable in Autoconf 2.62.
Thanks -- the patch seems to do a little more than just rename a
colliding variable (which I presume was "simplified"). I like the use of
m4_translit, assuming it is provided by a wide range of m4 versions.
Also, I presume the purpose of option_checking is to keep
--enable-option-checking working?
At the moment, only one package exists that installs only Bro.
Here is the CVS url: http://cvs.fedoraproject.org/viewvc/rpms/bro/
RPMs are here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=60298
And I forgot to mention that there was an another problem with "make
install" to a different DESTDIR. I wrote a patch for this which is
available in CVS
(http://cvs.fedoraproject.org/viewvc/rpms/bro/devel/bro-20080804-installpolicy.patch?revision=1.1).
Dan
Hi Stepan,
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
breakThis 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@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@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. :^)