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

[Roland McGrath <roland at redhat dot com>]

> 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.

I don't like this aspect of it.  I've committed a different change instead.
Now you want:

	libc_add_on_config_subdirs='bar baz/sub'

where those names are relative to the add-on source directory where that
configure fragment appears.  It does not matter what the name of the
add-on's top-level directory is (i.e. it can differ from what its
maintainer thinks it is).

> The minimal glibc/foo/configure.in needs to look like this.
> 
>      GLIBC_PROVIDES
> 
>      libc_add_on_canonical=foo

You do not need or want to set libc_add_on_canonical nonempty unless you
want to match sysdeps/.../foo subdirectories in other add-ons.  That's all
it's really for.  It will also set the build subdirectory name if you use
. in libc_add_on_subdirs, but that will just default to `basename $add_on`
and that will be fine.  You do need to set it to empty if nothing else,
just to keep configure from barfing on you.

A caveat to note is that neither the add-on source directory (as given to
--enable-add-ons) nor the $libc_add_on_config_subdirs elements can be
absolute directory names, whereas otherwise the add-on source directory can
be.  This is an autoconf limitation, so it can figure out what to call the
build subdirectory.  However, you can use a --enable-add-ons=../blah for a
blah add-on subdirectory sitting next to the main libc source directory.

Another general note about add-on configure fragments: you don't need to
write it as configure.in if you don't use any autoconf macros.  You can
just write configure directly (like nptl/configure) if you prefer.  

If you write a configure.in, then it has to start with GLIBC_PROVIDES.
This expands to nothing in the output configure file.  Its purpose there is
to prevent autoconf from emitting lots of hooey that your fragment does not
need or want, because it's already there in the top-level configure.
(Autoconf normally creates standalone configure scripts, but for add-on and
sysdeps configure fragments, we are "sourcing" the fragment with . inside
libc's configure script, rather than executing it as a standalone script.)


Thanks,
Roland