binutils+gdb CVS module

binutils+gdb CVS module

[Stephen Biggs]

Having just found this combination module (is this the same as
gdb+binutils??) and realizing that this is exactly what I need, I
checked it out and have been updating it daily from the
sources.redhat.com repository.

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.

Today, after tossing my sandbox and re-checking out, these directories
have disappeared again.  Nothing in the ChangeLog as far as I can see.

Should this module have these directories?  If not, why were they
there?  Just curious, as I see that this is part of what happens when
you stay on the bleeding edge.

Re: binutils+gdb CVS module

[Stephen Biggs]

On Mon, 2003-08-18 at 17:54, Daniel Jacobowitz wrote:
> On Mon, Aug 18, 2003 at 05:51:26PM +0300, Stephen Biggs wrote:
> > On Mon, 2003-08-18 at 15:56, Daniel Jacobowitz wrote:
> > > On Mon, Aug 18, 2003 at 05:04:44AM -0400, Michael Elizabeth Chastain wrote:
> > > > 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).
> > > 
> > > The trick is to update directories the same way you checked them out
> > > initially: say "cvs -d <root> co gdb+binutils" from the level above
> > > src, just like the first time.  That gets the right set of new files.
> > > 
> > 
> > I did a checkout like so:
> > $ cd ~/cvs
> > $ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src login
> > $ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src checkout
> > binutils+gdb
> > 
> > ... so, if I have ~/cvs/src being the top of my binutils+gdb tree (with
> > NO mention anywhere of binutils+gdb in the tree, fitting what Michael
> > said), from the level above, if I understand you correctly?
> > 
> > This doesn't work.
> > $ cd ~/cvs
> > $ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src update -R -d -P
> > binutils+gdb
> > cvs server: Updating binutils+gdb
> > cvs server: cannot open directory /cvs/src/binutils+gdb: No such file or
> > directory
> > cvs server: skipping directory binutils+gdb
> > $
> > 
> > What did I do wrong?
> 
> Try using "checkout" the second time too.  That's the key - update
> doesn't check the modules file, only checkout does.  Don't need to give
> it any other options than you did the first time.

Yes. That did the trick.  Thanks for the CVS tip!

As Bob Rossi said:  VERY cool!

> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 

Re: binutils+gdb CVS module

[Daniel Jacobowitz]

On Mon, Aug 18, 2003 at 05:51:26PM +0300, Stephen Biggs wrote:
> On Mon, 2003-08-18 at 15:56, Daniel Jacobowitz wrote:
> > On Mon, Aug 18, 2003 at 05:04:44AM -0400, Michael Elizabeth Chastain wrote:
> > > 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).
> > 
> > The trick is to update directories the same way you checked them out
> > initially: say "cvs -d <root> co gdb+binutils" from the level above
> > src, just like the first time.  That gets the right set of new files.
> > 
> 
> I did a checkout like so:
> $ cd ~/cvs
> $ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src login
> $ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src checkout
> binutils+gdb
> 
> ... so, if I have ~/cvs/src being the top of my binutils+gdb tree (with
> NO mention anywhere of binutils+gdb in the tree, fitting what Michael
> said), from the level above, if I understand you correctly?
> 
> This doesn't work.
> $ cd ~/cvs
> $ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src update -R -d -P
> binutils+gdb
> cvs server: Updating binutils+gdb
> cvs server: cannot open directory /cvs/src/binutils+gdb: No such file or
> directory
> cvs server: skipping directory binutils+gdb
> $
> 
> What did I do wrong?

Try using "checkout" the second time too.  That's the key - update
doesn't check the modules file, only checkout does.  Don't need to give
it any other options than you did the first time.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: binutils+gdb CVS module

[Stephen Biggs]

On Mon, 2003-08-18 at 15:56, Daniel Jacobowitz wrote:
> On Mon, Aug 18, 2003 at 05:04:44AM -0400, Michael Elizabeth Chastain wrote:
> > 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).
> 
> The trick is to update directories the same way you checked them out
> initially: say "cvs -d <root> co gdb+binutils" from the level above
> src, just like the first time.  That gets the right set of new files.
> 

I did a checkout like so:
$ cd ~/cvs
$ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src login
$ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src checkout
binutils+gdb

... so, if I have ~/cvs/src being the top of my binutils+gdb tree (with
NO mention anywhere of binutils+gdb in the tree, fitting what Michael
said), from the level above, if I understand you correctly?

This doesn't work.
$ cd ~/cvs
$ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src update -R -d -P
binutils+gdb
cvs server: Updating binutils+gdb
cvs server: cannot open directory /cvs/src/binutils+gdb: No such file or
directory
cvs server: skipping directory binutils+gdb
$

What did I do wrong?

> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 

Re: binutils+gdb CVS module

[Bob Rossi]

On Mon, Aug 18, 2003 at 08:56:51AM -0400, Daniel Jacobowitz wrote:
> On Mon, Aug 18, 2003 at 05:04:44AM -0400, Michael Elizabeth Chastain wrote:
> > 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).
> 
> The trick is to update directories the same way you checked them out
> initially: say "cvs -d <root> co gdb+binutils" from the level above
> src, just like the first time.  That gets the right set of new files.

Wooo, cool!

Bob Rossi

Re: binutils+gdb CVS module

[Daniel Jacobowitz]

On Mon, Aug 18, 2003 at 05:04:44AM -0400, Michael Elizabeth Chastain wrote:
> 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).

The trick is to update directories the same way you checked them out
initially: say "cvs -d <root> co gdb+binutils" from the level above
src, just like the first time.  That gets the right set of new files.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: binutils+gdb CVS module

[Michael Elizabeth Chastain]

Hi Stephen,

> How does one know when there is something new?  Add a watch via email? 
> Is that even allowed with this repository?

Watches are a big dead end as far I can tell.  They only work on files,
not on directories, and they require other people to do 'cvs edit'
to send the signal.  Anyways, gdb doesn't use them.

The usual procedure is to subscribe to gdb-cvs mailing list and
watch the commits go by.  Also, if your work area starts mysteriously
failing, look in the gdb mailing list and see if people are talking
about another round of top level changes.

AFAIK, the most recent new file was src-release on 2002-10-01.  So 'cvs
update' will fail about once a year.  Less, really, for an ordinary gdb
developer who is not making releases or editing the configuration
machinery (editing Makefile.tpl and stuff).

Me, I just do fresh "cvs checkout" a lot.  But I do more testing
than developing.

Michael C

Re: binutils+gdb CVS module

[Stephen Biggs]

Hi Michael,

On Mon, 2003-08-18 at 12:04, Michael Elizabeth Chastain wrote:
> 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".

Yes, exactly.

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

How does one know when there is something new?  Add a watch via email? 
Is that even allowed with this repository?

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

Thanks very much for the concise and informative reply.

> Michael C
> 

Re: binutils+gdb CVS module

[Michael Elizabeth Chastain]

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