This is the mail archive of the gdb-testers@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Problems with the new GDB repository source


On Mon, Feb 07, 2000 at 05:56:10PM -0800, Jimmy Guo wrote:

> Two issues / problems with the latest snapshot (of the public CVS
> repository):
> 
> 1) It seems like the tree structure uses the 4.18 structure.  Old files
>    which have since been removed in the GDB source (up to the 2/4
>    snapshot) are popping up again.  And some new files were removed in
>    the 2/6 tree.  Examples are:
>    - old files popping up again
>      ./gdb/testsuite/gdb.base/README,*.u,crossload.exp,
>      ./gdb/tui/Makefile, ...


Thanks for pointing this out.  I've had to remove files by hand during
the snapshot process for the last year (it was never supposed to go on
for more than a month or two....) and I've obviously missed many of
them. :-)  I did a full comparison between the trees and removed the
accumulated junk.


>    - new files disappearing:
>      ./libiberty/testsuite, ./texinfo/doc, ...

There was no reason for all of texinfo to be in GDB, this was an
opportunity to get rid of it.

As for libiberty, as I mentioned in the original announcement, the
top-level and shared directories are all coming in from the binutils
sourceware repository.  This repository is different from the one where
GDB was coming from (the Cygnus internal repo), and these two repos have
not been synchronized for maybe six months now.

That means that you'll see some steps backwards (like this) and you'll
see some steps forwards (improvements done in the binutils repo that
hadn't made it in to the Cygnus repo yet).

At some point in the future (I have no idea when), someone will merge the
sourceware binutils repo with the Cygnus binutils repo and the changes
that had been happening within Cygnus will get out there.


> 2) What was the procedure to determine which version of a file to use,
>    for things under bfd/, include/, etc.???

These files all came from binutils.

>    While we can submit a patch to add this back in, I'm really curious
>    to know how confident we are when we just take whatever binutils/
>    have and erase gdb's -- since it does look like no attention was paid
>    to introduce the changes in the gdb version into the binutils
>    version, before the binutils version was adopted, it does look like a
>    big problem when it comes to trusting the new public repository for
>    GDB development.

Yes, this was not ideal.  If I did not merge the repositories right
now, I can guarantee that it wouldn't happen for at _least_ another
month, and chances are extremely high that it would take much longer.
Remember, we've been wanting to make this change for well over a year.
We've tried to do it several times, but each time something came up so
we had to abort.

I know that the result looks like a step backward, but believe me,
I had to do it now and some pain was inevitable.  We'll get it worked out.

Any changes to the binutils repository (bfd, opcodes,
binutils, gas, ld) will need to go through the binutils project
(binutils@sourceware.cygnus.com).  Changes to the shared files are more
flexible, but we'll still need to coordinate with them.

If there is an important change that got dropped in this merge, let's
discuss it.  If something from include or libiberty got lost and is
needed, I'm sure we can merge it in without too much trouble.


Jason

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]