Re: [Patch] New target to generate cscope database

[Debarshi Ray]

>> I found a discussion involving Jesse Barnes
>> (http://sources.redhat.com/ml/automake/2004-07/msg00051.html) which
>> seemed inconclusive. I have tried this patch with Automake 1.10.2 and
>> the msmtp source base and it seems to work, but my knowledge of
>> Automake's internals and Perl is zero.

> Did you take any code from Jesse's patch?  In that case, the ChangeLog
> entry should list Jesse as author as well, and we might even need
> copyright papers from Jesse, too.

I have used the same set of options that Jesse had passed to
$(CSCOPE). Apart from that, there is not much in common. (Actually I
had started off by trying to rebase his patch against newer Automake
versions, but ended up rewriting it myself.)

> Does cscope offer enough additional functionality over, say,
> Exuberant Ctags or gtags, to warrant being supported?  Do many people
> use it?

I am not much of a ctags, etags, gtags or cscope user myself. I am
more comfortable with grep and find. However, most of my colleagues at
work are cscope users. Usually they have a small script that generates
the database and invokes cscope using it. This script is usually
copied around and end up being committed to the source tree. The
prolifiration of this scripts was a minor irritation to me, and I
decided to do something about it.

>From Jesse's mail, it looks as if cscope was popular around him too.

> What happens if sources other than C, Lex, or Yacc are listed in
> cscope.files?
>
> What if files are listed more than once in cscope.files?
>
> [...]
>
> The cscope.1 manpages I'm looking at allows to pass -Iincdir arguments,
> which directs cscope to search for included headers in 'incdir'.  What
> exactly is this used for, and would it still be beneficial to use even
> if all headers in the package are listed in *_HEADERS or *_SOURCES
> files? [...]

I will look into these get back to you.

> The HACKING file from the git tree lists several bits missing from
> this patch, namely tests ensuring that the new functionality works as
> desired (also see tests/README), a NEWS file entry.

Okay.

> FYI, in Automake we typically don't list any regenerated files in the
> ChangeLog entry.

Just to be clear on this, we should not mention the Makefile.ins in
both the 'git log' and the ChangeLog, right?

> Why are you using -R here, if the cscope.files file already lists all
> files recursively?  Isn't that duplicate, and won't it pick up all
> source files found in the tree, as opposed to only those belonging to
> the project (and not backup copies or so)?

I will look into this.

> "cscope" should be added to AM_RECURSIVE_TARGETS here.
>
> I suppose we should test that the cscope rule does not pick up arbitrary
> other files from the source tree.

Ok.

> Should we pass $(AM_CSCOPEFLAGS) $(CSCOPEFLAGS) to $(CSCOPE) too?
> If yes, that should be documented in the manual, too.

I think it is the other way around. I put them in the manual but not
in tags.am. In any case it is a mistake on my part.

>> +     for i in $$list; do \
>> +       echo $(abs_srcdir)/$$i >> $(top_builddir)/cscope.files; \
>> +     done
>
> Generated files shouldn't have an $(abs_srcdir) stuck in front of them,
> as they live in the build tree

What I am trying to do is put the cscope.files under $(top_builddir)
and put the paths to the actual source files inside cscope.files.

> ; for them you can use $(abs_builddir),
> or, even better, just $(subdir), as there is no need for absolute paths
> in this case.

When $(top_srcdir) == $(top_builddir), the value of subdir evaluates
to '.', while when $(top_srcdir) != $(top_builddir) the abs_builddir
won't lead to the path of the actual source files.

> $(abs_srcdir) uses should be double-quoted.
>
> [...]
>
> BTW, I'd put the >> redirection after the "done", so that it's done only
> once, that's a wee bit more efficient.
>
> [...]
>
> will cause all files to be listed at least twice in cscope.files?
> That should be fixed, the toplevel directory should truncate the file.

Okay.

Thank you for the review.

Happy hacking,
Debarshi
-- 
One reason that life is complex is that it has a real part and an
imaginary part.
    -- Andrew Koenig