This is the mail archive of the gdb@sources.redhat.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]
Other format: [Raw text]

Re: binutils+gdb CVS module


Hi Stephen,

> (is this the same as gdb+binutils??)

Yes, gdb+binutils and binutils+gdb are identical.
You can check out 'modules' and look in the modules list if you like.

> Yesterday, after the update, there were the directories libgloss, sid,
> tcl, and quite a few others which messed up my build because the target
> I am trying to develop has no idea about these things.

Sounds like you did "cvs update -d" instead of "cvs update".

This is a known deficiency with cvs.  When you do the initial checkout
of binutils+gdb, you get only the files and directories that are part
of this module.  But the name "binutils+gdb" is not recorded anywhere.

When you do "cvs update", your cvs client program doesn't know about
"binutils+gdb" any more.  It knows that you have a restricted subset of
the files and dirs from the server, but it doesn't know *which* subset.
So ... for all the files and dirs on the server which you *don't*
already have ... "cvs update" doesn't know whether you need them for
the module you checked out, because "cvs checkout" did not record the
name of the module that it checked out.

So there are two modes, both a little deficient.  In the plain "cvs
update" mode, cvs will update the top-level files and dirs that you
already have, but it won't create any new ones.  This correctly handles
all the files and dirs on the server that you don't want to see, like
libgloss, sid, and tcl.  But if someone actually DOES create a new file
at the top level, and the new file really IS part of binutils+gdb, cvs
won't fetch it.

In the "cvs update -d" mode, cvs will update everything, including
creating new files.  That's probably what happened to your work area.
Hundreds of megabytes of extra stuff show up, and your build breaks.
On the plus side, if someone created a new top-level file that you
needed, you did get it.

The normal workaround is to do "cvs update" almost all of the time, with
no "-d", and to handle new top-level files and directories specially.
Fortunately they don't appear very often (a few times a year).

That's issue as I understand it.  If someone who knows more wants to
correct me, just jump in.

Michael C


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