GNU bug report logs - #8111
after adding a(nother) subconfigure, rerunning make fails

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8111 in the body.
You can then email your comments to 8111 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: bug-automake <at> gnu.org
Subject: after adding a(nother) subconfigure, rerunning make fails
Date: Thu, 24 Feb 2011 20:36:22 +0100

Say I have a project with an up to date build tree.

Say I add a(nother) sub package, update toplevel configure.ac, then
rerun make.  Then the new sub/configure will not be rerun by the
triggered './config.status --recheck' thus make will later fail due to
nonexistent Makefile in the new subdirectory.

Not even rerunning autoreconf -v in the toplevel source directory, then
rerunning make, will fix this: you need to rerun configure in the (each)
build tree.

Can we fix this somehow in either Autoconf or Automake?

We could, by not passing --no-recursion upon --recheck, but doing that
all the time is probably not the best way to address this.  I'm not
quite sure if we can find out at 'config.status --recheck' time whether
the updated configure will enable the new sub configure.  Maybe a
--maybe-recursion?

Thanks,
Ralf

    Expose failure to run 'make' when new subpackage has been added.
    
    * tests/new-subpkg.test: New test.
    * tests/Makefile.am (TESTS, XFAIL_TESTS): Update.

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 2ffdb9b..d6e3664 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -24,6 +24,7 @@ all.test \
 auxdir2.test \
 cond17.test \
 gcj6.test \
+new-subpkg.test \
 override-conditional-2.test \
 txinfo5.test
 
@@ -633,6 +634,7 @@ mkinst3.test \
 mmode.test \
 mmodely.test \
 multlib.test \
+new-subpkg.test \
 no-outdir-option.test \
 nobase.test \
 nobase-libtool.test \
diff --git a/tests/new-subpkg.test b/tests/new-subpkg.test
new file mode 100644
index 0000000..b49e16d
--- /dev/null
+++ b/tests/new-subpkg.test
@@ -0,0 +1,66 @@
+#! /bin/sh
+# Copyright (C) 2011 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# make should work after adding a new subpackage.
+
+required='GNUmake'
+. ./defs || Exit 1
+
+cat >>configure.in <<'END'
+dnl AC_CONFIG_SUBDIRS([lib])
+AC_OUTPUT
+END
+
+: >Makefile.am
+
+$ACLOCAL
+$AUTOMAKE --add-missing
+$AUTOCONF
+./configure
+$MAKE
+
+sed 's/^dnl //' configure.in > configure.int
+mv -f configure.int configure.in
+
+cat >Makefile.am <<'EOF'
+SUBDIRS = lib
+EOF
+
+mkdir lib
+
+cat >lib/configure.ac <<'EOF'
+AC_INIT([lib], [1])
+AM_INIT_AUTOMAKE
+AC_CONFIG_FILES([Makefile])
+EOF
+
+: >lib/Makefile.am
+
+# Ideally, this would work.
+#$MAKE
+
+# But for a start, it would be good if even this would work.
+$ACLOCAL
+$AUTOMAKE
+$AUTOCONF
+cd lib
+$ACLOCAL
+$AUTOMAKE --add-missing
+$AUTOCONF
+cd ..
+$MAKE
+
+:

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: bug-automake <at> gnu.org
Subject: Re: bug#8111: after adding a(nother) subconfigure,
	rerunning make fails
Date: Fri, 25 Feb 2011 09:49:44 +1100

On Fri, Feb 25, 2011 at 6:36 AM, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
> Can we fix this somehow in either Autoconf or Automake?

Could we save the results of tracing AC_CONFIG_SUBDIRS calls? If
there's a change, invoke ./config.status --recheck. If not,
config.status --recheck --no-recursion.

-- Jack

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Jack Kelly <jack <at> jackkelly.name>, autoconf-patches <at> gnu.org
Cc: bug-automake <at> gnu.org
Subject: Re: bug#8111: after adding a(nother) subconfigure, rerunning make
	fails
Date: Fri, 25 Feb 2011 21:46:57 +0100

[ adding autoconf-patches; this is <http://debbugs.gnu.org/8111> ]

* Jack Kelly wrote on Thu, Feb 24, 2011 at 11:49:44PM CET:
> On Fri, Feb 25, 2011 at 6:36 AM, Ralf Wildenhues wrote:
> > Can we fix this somehow in either Autoconf or Automake?
> 
> Could we save the results of tracing AC_CONFIG_SUBDIRS calls? If
> there's a change, invoke ./config.status --recheck. If not,
> config.status --recheck --no-recursion.

Well, the rule that invokes 'config.status --recheck', let's call it the
config.status rule, does not invoke any autotools, thus no m4.  Any
rule that invokes m4 must be a developer rule, but the config.status
rule is a user rule, which is even in place with maintainer-mode.
So we cannot mix these two concepts.

(Aside, config.status --recheck invokes configure with --no-create and
--no-recursion added, among the other arguments.  Sorry for the
nitpicking.)

But I think we can still have our cake and eat it too: if I remove the
--no-recursion from the list of arguments passed to configure, then the
test starts to pass (once the missing AC_OUTPUT in the lib/configure.ac
is fixed).  Of course, we don't want to do that outright: if there is
already a makefile in the subdir, then we don't want to recurse: the
subdir makefile might want to run other rebuilding rules first.  But if
there isn't, and there is a configure script we can run, then I think we
should do that.  Since 'makefile' might be spelt in various different
ways, we can take presence of 'config.status' in the subdir build tree
as indicator, that should be good enough.

I'm still wondering whether we should rename the option
--new-recursion-only however, that would be more precise.
Other than that, the patch below seems to do what I want.

Comments?

(And of course the test will need to be rewritten for Autoconf's test
suite and amended to ensure we don't recurse when we shouldn't, and
documentation and all that ...)

Thanks,
Ralf

diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4
index 337aba7..ce80dde 100644
--- a/lib/autoconf/general.m4
+++ b/lib/autoconf/general.m4
@@ -751,7 +751,7 @@ do
 
   -no-recursion | --no-recursion | --no-recursio | --no-recursi \
   | --no-recurs | --no-recur | --no-recu | --no-rec | --no-re | --no-r)
-    no_recursion=yes ;;
+    no_recursion=new-only ;;
 
   -oldincludedir | --oldincludedir | --oldincludedi | --oldincluded \
   | --oldinclude | --oldinclud | --oldinclu | --oldincl | --oldinc \
diff --git a/lib/autoconf/status.m4 b/lib/autoconf/status.m4
index a1a857b..00d5721 100644
--- a/lib/autoconf/status.m4
+++ b/lib/autoconf/status.m4
@@ -1181,6 +1181,11 @@ if test "$no_recursion" != yes; then
     # parts of a large source tree are present.
     test -d "$srcdir/$ac_dir" || continue
 
+    # If recursing to new subpackages only, skip those that have makefiles.
+    if test "$no_recursion" = new-only && test -x $ac_dir/config.status; then
+      continue
+    fi
+
     ac_msg="=== configuring in $ac_dir (`pwd`/$ac_dir)"
     _AS_ECHO_LOG([$ac_msg])
     _AS_ECHO([$ac_msg])

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Jack Kelly <jack <at> jackkelly.name>, autoconf-patches <at> gnu.org,
	bug-automake <at> gnu.org
Subject: Re: bug#8111: after adding a(nother) subconfigure,
	rerunning make fails
Date: Sat, 26 Feb 2011 08:38:39 +1100

On Sat, Feb 26, 2011 at 7:46 AM, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
> [ adding autoconf-patches; this is <http://debbugs.gnu.org/8111> ]
>
> * Jack Kelly wrote on Thu, Feb 24, 2011 at 11:49:44PM CET:
>> On Fri, Feb 25, 2011 at 6:36 AM, Ralf Wildenhues wrote:
>> > Can we fix this somehow in either Autoconf or Automake?
>>
>> Could we save the results of tracing AC_CONFIG_SUBDIRS calls? If
>> there's a change, invoke ./config.status --recheck. If not,
>> config.status --recheck --no-recursion.
>
> Well, the rule that invokes 'config.status --recheck', let's call it the
> config.status rule, does not invoke any autotools, thus no m4.  Any
> rule that invokes m4 must be a developer rule, but the config.status
> rule is a user rule, which is even in place with maintainer-mode.
> So we cannot mix these two concepts.

If they are changing `configure.ac', they will be invoking developer
rules. I don't mean trace in the ./config.status --recheck rule, but
instead at `automake' time:

If there are any AC_CONFIG_SUBDIRS calls, write them out to a trace
file (such as build-aux/subdirs.trace). Save the previous trace as
build-aux/subdirs.trace.old. Now the rule to call config.status
--recheck needs to only run `diff'.

Having clarified myself, I think your method makes more sense (and has
no additional files to dist). Comments on that below.

> Since 'makefile' might be spelt in various different
> ways, we can take presence of 'config.status' in the subdir build tree
> as indicator, that should be good enough.

You should add a comment to this effect in your status.m4 changes.
Currently, it looks like you've tested for config.status by mistake.

> I'm still wondering whether we should rename the option
> --new-recursion-only however, that would be more precise.
> Other than that, the patch below seems to do what I want.

Yes. the name becomes very confusing. Maybe --recursion=no (with
--no-recursion as an alias), --recursion=new-only?

-- Jack

Message #19 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Jack Kelly <jack <at> jackkelly.name>
Cc: bug-automake <at> gnu.org
Subject: Re: bug#8111: after adding a(nother) subconfigure, rerunning make
	fails
Date: Sat, 26 Feb 2011 09:00:36 +0100

close 8111
thanks

This is not an Automake bug after all.  It can be solved completely
within Autoconf, thus no new version skew danger.  :-)

Patch for Autoconf coming up.

Thanks,
Ralf

Message #22 received at 8111 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 8111 <at> debbugs.gnu.org
Cc: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>, Jack Kelly <jack <at> jackkelly.name>
Subject: Re: bug#8111: after adding a(nother) subconfigure,
	rerunning make fails
Date: Sat, 26 Feb 2011 09:32:57 +0100

Hello Ralf.

On Saturday 26 February 2011, Ralf Wildenhues wrote:
> close 8111
> thanks
> 
> This is not an Automake bug after all.  It can be solved completely
> within Autoconf, thus no new version skew danger.  :-)
>
What about checking in your automake testcase anyway (obviously to
be skipped with autoconf <= 2.68)?  From a blackbox perspective, the
behaviour it tests is the desired and expected one, so IHMO it makes
sense to check for it, against (say) possible future automake and/or
autoconf regressions.

Thanks,
  Stefano

Message #25 received at 8111 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>, automake-patches <at> gnu.org
Cc: 8111 <at> debbugs.gnu.org, Jack Kelly <jack <at> jackkelly.name>
Subject: Re: bug#8111: after adding a(nother) subconfigure, rerunning make
	fails
Date: Sat, 26 Feb 2011 10:25:30 +0100

Hi Stefano,

* Stefano Lattarini wrote on Sat, Feb 26, 2011 at 09:32:57AM CET:
> On Saturday 26 February 2011, Ralf Wildenhues wrote:
> > This is not an Automake bug after all.  It can be solved completely
> > within Autoconf, thus no new version skew danger.  :-)
> >
> What about checking in your automake testcase anyway (obviously to
> be skipped with autoconf <= 2.68)?  From a blackbox perspective, the
> behaviour it tests is the desired and expected one, so IHMO it makes
> sense to check for it, against (say) possible future automake and/or
> autoconf regressions.

Yeah, that's what I figured too, but thanks for bringing it up.
I intend to push something like the patch below to maint when
the Autoconf API is cast in stone.

Cheers,
Ralf

    With new Autoconf, rebuilding works after adding a subpackage.
    
    * tests/new-subpkg.test: New test.
    * tests/Makefile.am (TESTS): Update.

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 047bc7b..aecbfb3 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -519,6 +519,7 @@ mkinst3.test \
 mmode.test \
 mmodely.test \
 multlib.test \
+new-subpkg.test \
 nobase.test \
 nobase-libtool.test \
 nobase-python.test \
diff --git a/tests/new-subpkg.test b/tests/new-subpkg.test
new file mode 100755
index 0000000..0b82a9a
--- /dev/null
+++ b/tests/new-subpkg.test
@@ -0,0 +1,71 @@
+#! /bin/sh
+# Copyright (C) 2011 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# `make' should work after adding a new subpackage to an existing tree.
+
+required='GNUmake'
+. ./defs || Exit 1
+
+cat >>configure.in <<'END'
+dnl AC_CONFIG_SUBDIRS([lib])
+AC_OUTPUT
+END
+
+: >Makefile.am
+
+$ACLOCAL
+$AUTOMAKE --add-missing
+$AUTOCONF
+
+# We need new-enough Autoconf that recurses new subpackages.
+./configure --help | grep 'recursion=.*new-only' || Exit 77
+
+./configure
+$MAKE
+
+sed 's/^dnl //' configure.in > configure.int
+mv -f configure.int configure.in
+
+cat >Makefile.am <<'EOF'
+SUBDIRS = lib
+EOF
+
+mkdir lib
+
+cat >lib/configure.ac <<'EOF'
+AC_INIT([lib], [1])
+AM_INIT_AUTOMAKE
+AC_CONFIG_FILES([Makefile])
+AC_OUTPUT
+EOF
+
+: >lib/Makefile.am
+
+# Ideally, this would work.
+#$MAKE
+
+# But for a start, being able to run make after a manual bootstrap is good.
+$ACLOCAL
+$AUTOMAKE
+$AUTOCONF
+cd lib
+$ACLOCAL
+$AUTOMAKE --add-missing
+$AUTOCONF
+cd ..
+$MAKE
+
+:

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.