libc add-ons changes

[Roland McGrath <roland at redhat dot com>]

I've checked in some makefile and configure changes to how add-ons work.
I've nominally tested things, but there are probably some loose ends.
Please keep an eye out for new oddities in your builds.

I have not yet updated maint.texi; if anyone wants to lend a hand with
that, it would be more than welcome.  For maintaining and using add-ons,
these are the differences:

* Add-ons no longer need to be unpacked inside the libc source tree.  An
  add-on directory can be located anywhere.  In the --enable-add-ons option
  you can list absolute directory names, or names relative to the source
  directory (I expect this will be the most common,
  e.g. ../glibc-ports-2.4), or names relative to the build directory.

  For those maintaining and distributing add-on tarballs, they can now
  contain a subdirectory called glibc-foobar-VERSION or whatever, in the
  normal convention.

* An add-on is not automatically added as a subdir in the libc build.
  To unconditionally add subdirs, an add-on's configure fragment must
  set the libc_add_on_subdirs variable to a list of subdirectories.
  This list can include . as a member to treat the add-on directory as a
  libc build subdir, as in the old style; libidn/configure.in does this.
  Build subdirs (still) may instead be included via sysdeps/.../Subdirs files.
  (This is how nptl works.)

* An add-on need not have a configure fragment.  An add-on that contains a
  sysdeps/ directory tree does not need also have a configure fragment if
  it has nothing to do.  Its sysdeps/ directories will still contribute to
  the search list, and any sysdeps/.../configure fragments will be run.
  For --enable-add-ons=yes, it will look for any subdirectories that
  contain either a sysdeps directory or a configure fragment.

  Each add-on is automatically searched for sysdeps/*/preconfigure fragments.
  This matches what the ports add-on's configure fragment used to do.
  These fragments are intended only to canonicalize $machine and $base_machine,
  so that the sysdeps search list will work.  This is now implicit so that
  add-on ports can contain nothing but the sysdeps/ directories for the port.

* configure fragment must set libc_add_on_canonical.  If an add-on has a
  configure fragment, it must set the variable libc_add_on_canonical to
  empty or to something.  This is the canonical name of the add-on, that's
  used as a possible subdirectory in the sysdeps tree of other add-ons;
  e.g. "linuxthreads", regardless of what the name of the add-on directory is.

* For each add-on that supplies sysdeps directories, its top-level
  directory is automatically added to the -I list (immediately after
  sysdeps directories).  This is so that #include <sysdeps/...> in add-on
  code can work to find other code in the add-on.  

  Note that this means that an add-on <sysdeps/foo.c> can no longer use
  #include <sysdeps/foo.c> to get the main source tree's file by the same
  name.  Instead, it can be done with some machinations using #include_next.
  There are several examples of this in nptl that I changed.

* sysdeps/generic directories in add-ons are no longer used.
  The -I switch for the top-level add-on directory means that
  headers can go there instead of in a sysdeps/generic subdirectory,
  and still be found by compilations in whichever build subdir.

I've probably forgotten something else I should mention.


Thanks,
Roland