Hi Debarshi,
* Debarshi Ray wrote on Thu, May 07, 2009 at 11:51:52AM CEST:
> >> 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.)
OK, thanks. You could add something like "Based upon an earlier patch
from Jesse Barnes" to the ChangeLog entry, for credit.
> > 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.
This sounds like a good motivation to write the patch. And really, I'm
not opposed to it at all. All I'm trying to find out is whether
supporting this tool is useful enough to warrant that every Makefile.in
file generated by automake carries another 20 lines of code.
> From Jesse's mail, it looks as if cscope was popular around him too.
Feedback from others helps too, yes, and callee site recording (thanks
Ben!) sounds like a good feature.
> > 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?
Yes. I'll generate a ChangeLog entry from your 'git log' entry or vice
versa, either way, doesn't matter.
> >> + 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.
Sure, I understood that. My point was that there can be source files
which are not distributed as part of the source tarball, but generated
only at 'make all' time. It would be nice if these source files were
taken into account for this list.
For example, if I have something like this
nodist_foo_SOURCES = generated.c
generated.c:
echo 'const char *datadir = "$(datadir)";' > $@
CLEANFILES = generated.c
in my Makefile.am, it would be nice if cscope found generated.c in the
build tree and not looked for it in the source tree.
The usual idiom for detecting this in a makefile is like this:
if test -f "$$i"; then echo "$(subdir)/$$i"; else echo "$(abs_srcdir)/$$i";
fi
(where I've used abs_srcdir as needed for your case now).
> > ; 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.
Sure, this is true for distributed source files.
Cheers,
Ralf
