forget *documenting* libiberty -- how about *installing* it?

[Phil Edwards <pedwards at disaster dot jaj dot com>]

The README file for libiberty starts off:

    This directory contains the -liberty library of free software.
    It is a collection of subroutines used by various GNU programs.
    ...
    We expect many of the GNU subroutines that are floating around to
    eventually arrive here.

I was writing the chunk of libiberty.texi on "how to use these subroutines
in various GNU programs that you the friendly user might be writing" when
I remembered that we never install header files for libiberty; only the
actual .a file.

We can't really expect people to make use of these utility subroutines if
they're not easy to use.  Not installing their headers, IMO, makes them
not easy to use.  :-)


I'm not concerned about the "makeup" functions like strncmp and friends;
those should be declared by the user in one form or another.

But things like obstacks, hashtab, all of the x* functions, etc, should be
declared only by including the proper header file, which the user would
have to dig out of GCC sources and then hope that there's no mismatch
between gcc/include/* and whatever installed libiberty.a is on the system.
Or dig out all of libiberty and build a fresh version, Just In Case.


Can we consider adding installation rules for the libiberty header files?
The only suggestion I have for "where" is the obvious one of "in a libiberty
subdir" so that users would need to write

    #include <libiberty/splay-tree.h>
    #include <libiberty/md5.h>

and so forth.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.