Re: Problem recursing configure into add-on's stand alone sub-project.

[Ryan Arnold <ryan dot arnold at gmail dot com>]

On Wed, Sep 9, 2009 at 10:12 AM, Ryan Arnold <ryan.arnold@gmail.com> wrote:
> I have an add-on 'foo' which I enable with
>
> --enable-add-ons=foo,nptl
>
> The addon 'foo' requires a sub-project to be statically linked into
> it. ÂWe'll call this 'bar'.
>
> Sub-project 'bar' is maintained officially out-of-tree and has it's
> own configure.ac and Makefile.in.
>
> So the structure is:
>
> glibc/foo/
> glibc/foo/configure.in
> glibc/foo/bar
> glibc/foo/bar/configure.ac
>
> The glibc/foo/configure.in looks like this:
>
> Â Â GLIBC_PROVIDES
>
> Â Â libc_add_on_canonical=dfp
>
> Â Â AC_CONFIG_SUBDIRS([bar])
>
> The GLIBC configure stage does indeed recurse into here and generates
> configure as:
>
> Â Â # This file is generated from configure.in by Autoconf. ÂDO NOT EDIT!
>
> Â Â libc_add_on_canonical=dfp
>
> Â Â subdirs="$subdirs bar"
>
> Unfortunately configure DOESN'T recurse into foo/bar/configure.in.
>
> Does anyone know how to get this to work? ÂThe documentation isn't helpful.
>
> I tried doing AC_CONFIG_SUBDIRS([foo/bar]) but that doesn't work.
>
> I've also tried adding libc_add_on_subdirs=bar to foo/configure.in but
> that doesn't work either.
>
> Outside of the glibc build system AC_CONFIG_SUBDIRS(bar) is enough to
> get this to work. ÂI suspect it's due to the 'addon' machinery.
>
> Ryan S. Arnold
>

Hi Roland, et al

Roland suggested the following fix, and I've verified that this works.

There are a few caveats which I will discuss below:

diff --git a/aclocal.m4 b/aclocal.m4
index 4efa41e..0000000 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -5,6 +5,7 @@ dnl AC_REQUIREs or AC_BEFOREs duplicatin
 dnl
 define([GLIBC_PROVIDES], [dnl
 AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl
+AC_PROVIDE([AC_CONFIG_SUBDIRS])dnl
 AC_PROVIDE([_AS_ECHO_N_PREPARE])dnl
 AC_PROVIDE([_AS_CR_PREPARE])dnl
 AC_PROVIDE([_AS_TR_SH_PREPARE])dnl
diff --git a/configure.in b/configure.in
index 4584afe..0000000 100644
--- a/configure.in
+++ b/configure.in
@@ -6,6 +6,9 @@ AC_CONFIG_SRCDIR([include/features.h])
 AC_CONFIG_HEADERS([config.h])
 AC_CONFIG_AUX_DIR([scripts])

+dnl This is here and in GLIBC_PROVIDES so that configure fragments can use it.
+AC_CONFIG_SUBDIRS()
+
 AC_CANONICAL_HOST

 AC_PROG_CC

With this fix the important thing to note is that
AC_CONFIG_SUBDIRS([<dir>]) MUST have the add-on in the path that's
used in <dir>, e.g.

The minimal glibc/foo/configure.in needs to look like this.

     GLIBC_PROVIDES

     libc_add_on_canonical=foo

     AC_CONFIG_SUBDIRS([foo/bar])

An additional point:

The add-on foo maintainer may find that the first time configure is
run, when foo/configure hasn't been generated, that foo/bar/configure
isn't run.

The file foo/configure isn't generated until the first invocation of
'make' detects that the add-on foo needs to be generated.  The way
around this is to base level configure glibc, make (at least through
the configure stage), and then reconfigure to verifty that the add-on
builds correctly.  Then distribute add-on foo with a pregenerated
'foo/configure'.  In this way the top-level configure for the
client/customer/user will invoke foo/bar/configure.

Thanks for the fix Roland.