cscope

Bugs item #656286, was opened at 2002-12-19 14:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=656286&group_id=4664

Category: C lexer/parser
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Gaurav Gupta (ggupta98)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: input in flex scanner failed

Initial Comment:
I'm running a Red Hat linux 7.2 (kernel 2.4.7) on intel 
platform. I've downloaded and installed the cscope 15.4 
using the instruction given in INSTALL file (by executing 
configure --with-flex, make and make install). I've then 
made a list of source code files at the top directory the 
cacope is required to start browsing files  (I've 
used "find ./ -name *.[ch] -print > cscope.in ).  I've then 
gone ahead to execute "cscope -i cscope.in" and 
got "Building cross-reference...input in flex scanner 
failed" error.  I don't know how to get rid of this problem, 
can some one help, please?

----------------------------------------------------------------------

Comment By: Gaurav Gupta (ggupta98)
Date: 2002-12-20 08:05

Message:
Logged In: YES 
user_id=672368

Thanks broeker,

The culprit files have been identified by "xargs wc < 
cscope.in" run. I've removed those files from the cscope.in 
and cross-references build was succeeded.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-12-19 14:59

Message:
Logged In: YES 
user_id=27517

The error message means that flex couldn't read one of the
files found in the list.  To test which that was, you may
want to inspect that cscope.in file, or just give it a dry
run:

	xargs wc < cscope.in

Anyway, using 'find' in this particular way isn't really
useful.  You could just as well have run

	cscope -R

and been doen with it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=656286&group_id=4664

On Tue, 10 Dec 2002, Kerr Shannon-SKERR1 wrote:

> Great.  Thanks for the comments.  We do use the -q mode already.  As far as
> how big do they get, right now they get up to around 20 mb, but I'm working
> on a method to include only the actual files being used in a software build.

On a reasonably fast machine, 20 Megs of sources shouldn't have to be
split up, I think.  ClearCase may confuse the matter, though, because of
the way it simulates much, but sometimes not enough of the behaviour of a
real Unix filesystem.  Ie. I wouldn't want to bet on cscope being able to
avoid re-parsing files that haven't changed since the last database build,
based on time-stamps.

> When I'm building a cscope database and I have a file list of several
> thousand files, if I have duplicate file names appearing in different
> directories, how would cscope know, for instance, which header I was
> talking about?

For the purpose of the filename list file (option -i, or "cscope.files"),
cscope expects you to give full path names, and those will be recognized
as different.

For header files, ie. the "files #including this file" search, cscope
cannot know what the -I flags are that you would be passing to the
compiler on building a particular file, so it has no way of knowing which
file called "foo.h" a given source's #include "foo.h" really refers to.

This is different only if the -I flags are the same for all source files
--- in that case, you can pass the same set to cscope and get an exact
picture.  

Turning this around means that you cannot search for only those files that
include a particular "foo.h" out of many spread around the source tree ---
you'll get all that #include "foo.h", regardless of which that will be.

-- 
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.

Hans-Bernhard Broeker wrote:

> On a reasonably fast machine, 20 Megs of sources shouldn't have to be
> split up, I think.  ClearCase may confuse the matter, though, because of
> the way it simulates much, but sometimes not enough of the behaviour of a
> real Unix filesystem.  Ie. I wouldn't want to bet on cscope being able to
> avoid re-parsing files that haven't changed since the last database build,
> based on time-stamps.

      20 Megs of sources is nothing (assuming local sources or sources 
accessed via NFS -- don't know about clearcase).  I used to index 
several hundred megabytes of sources nightly.  While building the index 
took a while (15-30 minutes on a medium-fast system?), searching was 
relatively fast (I think 20-40 seconds, accessing the database via NFS). 
  Searching a smaller database (~100MB, size of cscope.out is around 
23MB) takes something like 8-20 seconds (once in cache, the search time 
can be under 2 seconds).

      On Shannon's other topic, cscope interfaces for both vim and 
XEmacs exist.  I use the XEmacs one routinely, with multiple databases 
(I'm the maintainer).

-- Darryl

On Tue, Dec 10, 2002 at 10:30:40PM -0800, Darryl Okahata wrote:
> 
> 20 Megs of sources is nothing (assuming local sources or sources 
> accessed via NFS -- don't know about clearcase).  I used to index 
> several hundred megabytes of sources nightly.  While building the index 
> took a while (15-30 minutes on a medium-fast system?), searching was 
> relatively fast (I think 20-40 seconds, accessing the database via NFS). 
>   Searching a smaller database (~100MB, size of cscope.out is around 
> 23MB) takes something like 8-20 seconds (once in cache, the search time 
> can be under 2 seconds).

I also used to use cscope on a database much bigger than the Linux
source (a proprietary Unix kernel--was at least 2x bigger).  When I
started passing the -q option to cscope, searches went from 20 seconds
to almost instantaneous.  There's a big difference between O(n) and
O(1), i.e. linear vs. constant time.  So make sure to pass -q if you're
making a truly large database.

-- 
/***************************************************************
 | Jason Duell                              <jcduell@...>
 | NERSC Future Technologies Group          Tel: +1-510-495-2354
 | Lawrence Berkeley National Laboratory    Fax: +1-510-495-2998
 |
 | "Computing will never be free until the last software patent 
 |  examiner is strangled with the entrails of the last 
 |  Microsoft employee."
 ***************************************************************/

Darryl Okahata wrote:

>      20 Megs of sources is nothing (assuming local sources or sources 
> accessed via NFS -- don't know about clearcase).  I used to index 
> several hundred megabytes of sources nightly.  While building the index 

OK, I resurrected my indexing script, and re-ran it.  Here's another 
data point:

* 18053 files, occupying over 415MB.

* Files are accessed via NFS, over a 100BT LAN.

* Indexing time is just under five (5) minutes.  Note that this is
   without the -q option.

   [ Also note that this is done using a slightly older version of
     cscope, one using AT&T lex for fast performance.  I'm not sure how
     the current flex-based ones perform.  ]

* Resulting cscope.out is 139010159 bytes in size (stored on a local
   disk).

* Searching cscope.out ("cscope -d -L -0 main") takes under 7 seconds.

-- Darryl

Thanks for all the valuable information.  First let me say that the database
that I mentioned is built using the next-to-latest cscope with the -q option
and is a very small build only for our group.  Other groups in our
organization are building much larger databases and we were thinking of
their benefit as well.

The reason we were even looking into splitting the cscope.files file up,
building the db's on 5 separate machines in parallel and then linking the
databases together, was to shave off any time possible with our build
procedure.  We build a global cscope database, among other things, with our
total build procedure and at any stage of the procedure, if we can save any
time at all, we increase our productivity.

The cscope database build was just one point we were looking at trying to
save a little bit of time.  We were able to identify 600+ files that do not
belong in the build and this should save us some time in the db build and
also in the lookup time for our development team.  Any idea on the savings?

Thanks for all of your comments.

Shannon

On Thu, 12 Dec 2002, Kerr Shannon-SKERR1 wrote:

> The reason we were even looking into splitting the cscope.files file up,
> building the db's on 5 separate machines in parallel and then linking the
> databases together, was to shave off any time possible with our build
> procedure.  

To me, this sounds like suboptimal planning.  There's no particular reason
cscope.out databases must be built as internal part of the "build
procedure", which I assume means some kind of automated "build current
version from scratch" script.  But it should be able to run it in parallel
with other tasks of that job.  There's no need to wait for the cscope db
build, I think.  Or if there is, you could still do that on one machine,
and use the other 4 to run the actual code build.

> The cscope database build was just one point we were looking at trying to
> save a little bit of time.  We were able to identify 600+ files that do not
> belong in the build and this should save us some time in the db build and
> also in the lookup time for our development team.  Any idea on the savings?

If you have files that aren't part of the build, don't list them in your
cscope.files at all.  The design of cscope assumes that you have one
database per stand-alone product (program, library).  Code you don't use
for making a product shouldn't usually be in the cscope database for that
product.

-- 
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.

> To me, this sounds like suboptimal planning.  There's no particular reason
> cscope.out databases must be built as internal part of the "build
> procedure", which I assume means some kind of automated "build current
> version from scratch" script.  But it should be able to run it in parallel
> with other tasks of that job.  There's no need to wait for the cscope db
> build, I think.  Or if there is, you could still do that on one machine,
> and use the other 4 to run the actual code build.

Suboptimal planning?  You can make a statement like that without even
knowing our build process?  No offense, but before you make a comment like
that, I would think you'd need a little more information about the current
process.

Actually, the building of the cscope.out can be and is run in parallel with
other tasks, so I'm not sure what made you think that it wasn't.  But still,
the task takes time and for any task in our build process, we would like to
save time.  That makes sense, right?  It's just an ongoing optimization of
the build process.

> I didn't mean for this topic to turn out the way it did.  I was just
looking for some > insight on the possibility of linking together cscope.out
files.  That was it.
> If you have files that aren't part of the build, don't list them in your
> cscope.files at all.  The design of cscope assumes that you have one
> database per stand-alone product (program, library).  Code you don't use
> for making a product shouldn't usually be in the cscope database for that
> product.

As far as not including files that were not part of the build, I did not,
nor did any of the people currently working here, setup our current cscope
database generation process (perhaps this part could be validly
characterized as "suboptimal planning").  We are just cleaning up the build
process to maximize its performance.  That was why I stated

"We were able to identify 600+ files that do not belong in the build and
this should save us some time in the db build and also in the lookup time
for our development team."

We are removing files that are not used in the build.

I really appreciate everyone's insight and knowledge sharing for this
thread.

Thanks,

Shannon

On Fri, 13 Dec 2002, Kerr Shannon-SKERR1 wrote:

> > To me, this sounds like suboptimal planning.  There's no particular reason

Sorry if this came across stronger than it was meant to be.  English is
not my first language, no matter how much practice I've gained in it...

[...]
> Suboptimal planning?  You can make a statement like that without even
> knowing our build process?  No offense, but before you make a comment like
> that, I would think you'd need a little more information about the current
> process.

That's why I said it "sounded like" not quite optimal planning of that
procedure --- because it was an assessment based on obviously incomplete
information.  I was under the impression that the time you wanted to
minize was the total time from start of build to completion of all
subtasks, and I failed to imagine how cscope.out building time could
currently be the limiting part of that.  I.e. as long as it's done before
the actual compile and link, nor does it delay the start of that, who
cares how long it takes?

> Actually, the building of the cscope.out can be and is run in parallel with
> other tasks, so I'm not sure what made you think that it wasn't.  

Nothing but lack of any statement to the contrary...

But let's set the heated part of this discussion aside, and return to hard
software design, shall we?

Cscope database building from scratch, in -q mode, really is split into
two separate phases:

1) generation of cscope.out, the main database
2) generation of the inverted index into that (cscope.out.{po,in})

Now, if linking of several databases were to be added, this could be
done in several ways:

*) keep individual cscope.out's, but construct a common inverted index.
   Possible, but this would require modifying the innards of invlib.c.
   I don't think anyone in the team would dare trying that road --- 
   invlib is an absolute maintenance nightmare.  This may be open to
   re-evaluation once we managed to replace this by Berkeley DB, as
   planned.

*) keep individual cscope.out's, each with their own inverted index.
   This would increase -q mode search times proportional to the number
   of cscope.out's involved, and thus not be a very useful approach.

*) combine the cscope.out's after generation, then generate a common
   inverted index.  This should work, but it wouldn't gain anything,
   since cscope.out build time is linear in input size.  It'll actually
   be slower, because common headers would be parsed repeatedly, and the
   combination process would have to eliminate those duplicates.

-- 
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.

Your English is fine.  I've never thought this was getting heated.  Just
good discussion.  I've really been after just one goal, and that is to see
if it is possible to optimize this portion of the build.

btw, we wouldn't build the cscope database until the build completed
successfully, but that's another discussion.

Actually, you are correct, I am trying to reduce the time of the entire
build process itself, but I am looking at it from two standpoints:

1. Reducing the time of the overall process, by trying to run steps in
parallel
2. Reducing time of individual steps

Both of these, in my opinion, impact the build process positively.

I appreciate your explanation of the possible options for splitting up the
build and combining the cscope.out files.  To tell you the truth, we were
just sitting around discussing possibilities when this idea came up from a
colleague of mine, and I thought it sounded good and so I brought it to the
experts (all of you) and rightly so.  You've all provided the information we
were looking for and I appreciate your explanations.

So far, it looks like my best option for optimal cscope database build time
and optimal lookup time is to scrutinize what is actually being included in
cscope.files.  That's what I've been working towards for the last couple of
weeks now and have identified real savings in this area.

If no one sees possible time savings in this area (linking cscope
databases), then let me thank everyone for their input.

-Shannon

Bugs item #651667, was opened at 2002-12-10 14:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=651667&group_id=4664

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: recent version of Bison fails on egrep.y

Initial Comment:
Tried to compile cscope source (release 15.4) under 
cygwin(setup release 2.249.2.5). It fails quickly with the 
following messages:

command being run by make:

           bison -y egrep.y && mv y.tab.c egrep.c

errors:
           egrep.y:106.3: parse error, unexpected "=", 
expecting ";" or "|"

same error shows up at lines 111.3, 120.3 124.3 134.3
another error:
            egrep.y:113.4-26: invalid $ value
same error shows up at 115.4-26 too.

Version levels of different modules in cygwin:
bash-2.05b-8
binutils-20021117-1
bison-1.75-1
byacc-1.9-1
cmake-1.4.6-1


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-12-11 09:25

Message:
Logged In: NO 

Since this is part of cscope project, I wonder if egrep.y is 
being fixed and what the fix is, to avoid using the depricated 
interfaces in yacc/bison.

Honestly, I am not yacc/bison expert, but a user of cscope in 
daily life.

So, I can read a bit of man bison man page, and try fixing it 
myself for now, and if it works, let the community know.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-12-11 06:49

Message:
Logged In: YES 
user_id=27517

After some further digging, I found this ={...} syntax is
documented as a deprecated alternative to plain {...}, and
has been so for an amazing 24 years now, according to one of
the Bison guys.

Fixed by converting to correct syntax.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-12-11 04:03

Message:
Logged In: YES 
user_id=27517

Hmm.. this is a bit of a puzzle.  I've looked into the man
pages of both Unix yacc and GNU bison, but couldn't find any
mention of the "={" syntax found in those lines of the file.

For the moment, I take it this means that the version of
bison you have (1.75) cannot be used with this rather old
parser source code any more.
Or, to put it another way round, the newer Bison seems to
have broken backward compatibility to YACC in some way.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=651667&group_id=4664

Bugs item #651667, was opened at 2002-12-10 23:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=651667&group_id=4664

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: recent version of Bison fails on egrep.y

Initial Comment:
Tried to compile cscope source (release 15.4) under 
cygwin(setup release 2.249.2.5). It fails quickly with the 
following messages:

command being run by make:

           bison -y egrep.y && mv y.tab.c egrep.c

errors:
           egrep.y:106.3: parse error, unexpected "=", 
expecting ";" or "|"

same error shows up at lines 111.3, 120.3 124.3 134.3
another error:
            egrep.y:113.4-26: invalid $ value
same error shows up at 115.4-26 too.

Version levels of different modules in cygwin:
bash-2.05b-8
binutils-20021117-1
bison-1.75-1
byacc-1.9-1
cmake-1.4.6-1


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-12-11 18:28

Message:
Logged In: YES 
user_id=27517

Egrep.y *is* fixed already, but obviously only in the CVS
version only, for now. Go figure.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-12-11 18:25

Message:
Logged In: NO 

Since this is part of cscope project, I wonder if egrep.y is 
being fixed and what the fix is, to avoid using the depricated 
interfaces in yacc/bison.

Honestly, I am not yacc/bison expert, but a user of cscope in 
daily life.

So, I can read a bit of man bison man page, and try fixing it 
myself for now, and if it works, let the community know.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-12-11 15:49

Message:
Logged In: YES 
user_id=27517

After some further digging, I found this ={...} syntax is
documented as a deprecated alternative to plain {...}, and
has been so for an amazing 24 years now, according to one of
the Bison guys.

Fixed by converting to correct syntax.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-12-11 13:03

Message:
Logged In: YES 
user_id=27517

Hmm.. this is a bit of a puzzle.  I've looked into the man
pages of both Unix yacc and GNU bison, but couldn't find any
mention of the "={" syntax found in those lines of the file.

For the moment, I take it this means that the version of
bison you have (1.75) cannot be used with this rather old
parser source code any more.
Or, to put it another way round, the newer Bison seems to
have broken backward compatibility to YACC in some way.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=651667&group_id=4664

Bugs item #651667, was opened at 2002-12-10 14:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=651667&group_id=4664

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: recent version of Bison fails on egrep.y

Initial Comment:
Tried to compile cscope source (release 15.4) under 
cygwin(setup release 2.249.2.5). It fails quickly with the 
following messages:

command being run by make:

           bison -y egrep.y && mv y.tab.c egrep.c

errors:
           egrep.y:106.3: parse error, unexpected "=", 
expecting ";" or "|"

same error shows up at lines 111.3, 120.3 124.3 134.3
another error:
            egrep.y:113.4-26: invalid $ value
same error shows up at 115.4-26 too.

Version levels of different modules in cygwin:
bash-2.05b-8
binutils-20021117-1
bison-1.75-1
byacc-1.9-1
cmake-1.4.6-1


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-12-11 09:47

Message:
Logged In: NO 

Yes, without any reading the man yacc/bison pages, I 
changed the egrep.y to conform to the new syntax as 
suggested, and the compilation went well. And the cscope 
binary is working fine too. I have also used ctags with this 
cscope all under cygwin/x86.

So, I guess, those lines in egrep.y with "={...}" can be safely 
changed in the source base to use "{...}".  There are only 4 or 
5 such cases between lines 105 and 130.

Thanks.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-12-11 09:28

Message:
Logged In: YES 
user_id=27517

Egrep.y *is* fixed already, but obviously only in the CVS
version only, for now. Go figure.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-12-11 09:25

Message:
Logged In: NO 

Since this is part of cscope project, I wonder if egrep.y is 
being fixed and what the fix is, to avoid using the depricated 
interfaces in yacc/bison.

Honestly, I am not yacc/bison expert, but a user of cscope in 
daily life.

So, I can read a bit of man bison man page, and try fixing it 
myself for now, and if it works, let the community know.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-12-11 06:49

Message:
Logged In: YES 
user_id=27517

After some further digging, I found this ={...} syntax is
documented as a deprecated alternative to plain {...}, and
has been so for an amazing 24 years now, according to one of
the Bison guys.

Fixed by converting to correct syntax.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-12-11 04:03

Message:
Logged In: YES 
user_id=27517

Hmm.. this is a bit of a puzzle.  I've looked into the man
pages of both Unix yacc and GNU bison, but couldn't find any
mention of the "={" syntax found in those lines of the file.

For the moment, I take it this means that the version of
bison you have (1.75) cannot be used with this rather old
parser source code any more.
Or, to put it another way round, the newer Bison seems to
have broken backward compatibility to YACC in some way.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=651667&group_id=4664

Bugs item #652163, was opened at 2002-12-11 18:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=652163&group_id=4664

Category: None
Group: None
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: David M. Colclasure (dave_ancon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing file for AIX install

Initial Comment:
The following message received when trying to 
install CScope on AIX ver 4.3.3:

Making install in src
        bison -y   egrep.y && mv y.tab.c egrep.c
bison: /opt/local/share/bison.simple: No such file 
or directory

dave_ancon

----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-12-11 18:31

Message:
Logged In: YES 
user_id=27517

There's absolutely nothing the cscope team can do about that
problem. That's quite clearly caused by a broken bison
installation.  Maybe you just forgot to 'make install' at
the end of it, or something else didn't work as planned. 
Fix that, and try again.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=652163&group_id=4664

Bugs item #651667, was opened at 2002-12-10 23:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=651667&group_id=4664

>Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: cygwin/bison fails on egrep.y

Initial Comment:
Tried to compile cscope source (release 15.4) under 
cygwin(setup release 2.249.2.5). It fails quickly with the 
following messages:

command being run by make:

           bison -y egrep.y && mv y.tab.c egrep.c

errors:
           egrep.y:106.3: parse error, unexpected "=", 
expecting ";" or "|"

same error shows up at lines 111.3, 120.3 124.3 134.3
another error:
            egrep.y:113.4-26: invalid $ value
same error shows up at 115.4-26 too.

Version levels of different modules in cygwin:
bash-2.05b-8
binutils-20021117-1
bison-1.75-1
byacc-1.9-1
cmake-1.4.6-1


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-12-11 13:03

Message:
Logged In: YES 
user_id=27517

Hmm.. this is a bit of a puzzle.  I've looked into the man
pages of both Unix yacc and GNU bison, but couldn't find any
mention of the "={" syntax found in those lines of the file.

For the moment, I take it this means that the version of
bison you have (1.75) cannot be used with this rather old
parser source code any more.
Or, to put it another way round, the newer Bison seems to
have broken backward compatibility to YACC in some way.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=651667&group_id=4664

On Mon, Dec 09, 2002 at 03:47:56PM -0600, Kerr Shannon-SKERR1 wrote:
> All,
>  
> Anyone know how to link several databases together?  I want to build
> portions of a database on several machines, splitting up the work, and
> then link them together.  Hopefully, this will save us a significant
> amount of time building our rather large cscope database.

If you use the vim or emacs plugins, you can use several cscope
instances at once--just ":cscope add ..." multiple times (this example
is vim: I don't know emacs).  All added cscope instances will be
searched when you do a cscope search within the editor.

You're not going to get plain old cscope to link databases together.  If
your data is that big, you'll want to use the '-q' flag to speed up
searches, and it relies on an inverted index that doesn't make sense
outside the context of the cscope.out file.  This is not to say it's
impossible conceptually--I'm sure you could make such a thing work if
you waded into the cscope database code and tweaked for long enough.
But trust me, you don't want to (and we're going to be upgrading the
database to use Berkeley DB one of these days, anyway).

Cheers,

-- 
/***************************************************************
 | Jason Duell                              <jcduell@...>
 | NERSC Future Technologies Group          Tel: +1-510-495-2354
 | Lawrence Berkeley National Laboratory    Fax: +1-510-495-2998
 |
 | "Computing will never be free until the last software patent 
 |  examiner is strangled with the entrails of the last 
 |  Microsoft employee."
 ***************************************************************/

On Mon, 9 Dec 2002, Kerr Shannon-SKERR1 wrote:

[A side remark first: please don't mail HTML, nor "both HTML and plain
text".  It's a pointless waste of bandwith.]

> Anyone know how to link several databases together?  I want to build
> portions of a database on several machines, splitting up the work, and
> then link them together.  Hopefully, this will save us a significant
> amount of time building our rather large cscope database.

I'm quite sure no such method exists.  Cscope could be extended that way,
but I don't think the possible benefits are worth the effort.  All
searches would become one level more complicated, and the overall machine
load for generating the database would not really differ --- it's all
essentially linear in the input size.  So the only noticeable effect would
be the latency: the wallclock time needed for a DB build or update.

Just out of curiosity: how large *are* those databases you're going to set
up?  Seriously larger than, say, a cscope.out of the Linux kernel tree?

I second Jason's argument about -q mode: you should be using that for all
truly large databases.  But that in turn invalidates the possible gains
from splitting up the database even further, because it several small -q
inverted indexes would be slower to query than a single, larger one.

-- 
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.