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

[Ryan Arnold]

On Tue, 2009-09-15 at 11:52 -0500, Ryan Arnold wrote:
> 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.

As a follow-up, here's a link to the git commit for Roland's fix.

http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=7967983fd42380b090a63b53fe57a05e1d1c0b4f

It looks like he resolved the issue with AC_CONFIG_SUBDIRS needing a
add-on relative path.  I'll try it out with just
AC_CONFIG_SUBDIRS([bar]).

Ryan S. Arnold