Re: libiberty includes

[DJ Delorie <dj at delorie dot com>]

> That was why I sent you that other [private] message about the best
> version of libiberty to use.  I took libiberty/ and include/ from latest
> GCC sources after your message.  I then went to import Binutils 2.10.1
> and realized I'd be spamming my new libiberty headers files.  So it seems
> I'm left with taking the 2.10.1 include/ and removing the libiberty/
> headers and then importing the remaining headers.

Import all of include/ from binutils, then import the latest
gcc/include/* on top of them.  I think you're doing the right thing,
but in the wrong order.

> While that isn't so bad, it does make it harder to produce a set of their
> local diffs by cd'ing into include/ and doing something like
> ``cvs diff -rLIBIBERTY_20001223'' or ``cvs diff -rBINUTILS_2_10_1'' and
> getting a full list of changes.

Yeah, tags don't work as well if you're outside the original tree.

But, you can import a released binutils, then tag your local cvs, then
import a released gcc and tag that, then copy the latest libiberty on
top of them both and tag that.  Then you can do diffs like "what
changed by using the latest libiberty?"

Or, compare the libiberty/Changelogs from the two releases and see
which has newer entries, and import that package after the other.

> Since Cygnus deals with this, I was hoping for any lessons learned to be
> passed on.

I just keep everything in sync, all the time.  Like I said in the
private reply, libiberty hasn't broken compatibility in a long time,
so using the latest out of cvs (either gcc's or binutils's) should be
OK with older packages.

> Yes, I know.  I think you have mistaken how I was claiming updates
> happen.  I was using "import" loosely.  I can see how you would think I
> meant CVS vendor import, but how did you think I mean copying the ,v
> files?

I couldn't think of anything else that would destroy historical CVS
tags.