libiberty includes

[DJ Delorie]

> Would it be acceptable to copy the libiberty includes into its own
> directory, or into the libiberty directory itself?

As libiberty maintainer (btw, libiberty issues belong on the gcc lists
too, since the master copy is there) I wouldn't approve.  I would
consider it an unneeded change that would affect many packages and
would be a migration coordination nightmare.

But, if the various package committees (gcc, binutils, gdb, cygwin,
newlib) all agreed to do it, I'd go along.

> With them currently in the shared binutils include dir, it is hard
> to do things with just the binutils includes.

Examples?

> For instance, when Cygnus updates their internal tree, I assume they
> import libiberty bits from egcs/{include,libiberty}, and other .h
> files from binutils' src/include/.

First off, don't worry about what happens inside Cygnus (now Red Hat).
That's our problem, not yours.

Second, the updates don't work that way.  I merge from gcc to src
regularly.  Any include/* that exists in gcc/include is mastered in
gcc's cvs, and copied verbatim to src/include (via cvs commit, not by
copying *,v files).  Files that exist only in src/include I ignore.
My scripts monitor libiberty every *hour* and I usually do these
updates the same day I notice the changes.

I normally update Cygnus's internal files at the same time, and the
same way.  The binutils update for us only needs to look at
src/include/*, since the libiberty parts are already identical.

> But doesn't that end up being a PITA

As the libiberty maintainer, I do this all the time.  I have a script
which does most of the work, and it knows all about these things.
Having the includes mixed like this is not a problem for me, and
separating them will not make things any easier, but it *will* cause
problems throughout all the packages that use libiberty.

The only tricky bit is the Changelog entries, and I have a special
perl script that reads them all and tells me which entries in A are
missing in B.

> as the CVS tags w/in the internal include/ dir aren't consistent
> (ie, all files have the same tags), etc..

I do merges at the "cvs commit" level, so all tags are preserved.
Tags should be used for releases, and there's no point in copying
release tags from gcc's cvs to binutils's cvs.