libiberty includes

[Jeffrey A Law]

 In message < 200012271805.NAA03033@envy.delorie.com >you write:
  > 
  > > 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.
One thing that will make all this easier is to put a full "include" tree
in GCC, not this hokey minimalist thing we do in gcc/include right now.

The idea is it should be easier to diff the two tree (until we have a single
unified CVS tree) and make sure they stay in sync.

It's been on my todo for a while, but I haven't gotten around to it yet.

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


  > 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?"
Yup.  That's basically what Red Hat does when we import binutils, gdb, gcc,
etc into our internal unified CVS tree.  

jeff