Re: [PATCH] build: generate cscope and etags source indexes

[Jani Nikula <jani@nikula.org>]

On Thu, Aug 24, 2017 at 12:13 PM, Yuri Volchkov <yuri.volchkov@gmail.com> wrote:
>>> $ git ls-files | gtags -f -
> I was trying to adapt developing patterns from the linux kernel, to
> which I used to. This was my bias :)
>
> The good thing about this approach is that only those files will be
> indexed, which are actually build in the current configuration. For
> linux it is absolutely must, because there is a huge number of
> functions, implemented differently for different architecture or
> configuration option. So only relevant files are getting into the
> index.
>
> However, I agree, a relatively small project as notmuch, almost does not
> suffer from this problem.

FWIW I use the above snippet also for kernel work. More often than not
I want to find all the references. I think this is even more so for
notmuch, where you're more likely to do project wide refactoring.

>>> In theory you'll be able to look at $(SRCS) for indexing... but those
>>> are only the .c/.cc files. Are your tools clever enough to follow
>>> #include directives to index the headers as well?
> Oops. Honestly this thing have slipped from my mind. I'll fix this if we
> decided this feature is needed, and if the result will not look too ugly.

Not that the kernel tags targets are a good example for anything, but
they do use a bunch of complicated shell scripting to find the sources
in the file system. They don't look at the sources defined by
Makefiles for the configuration options. Figuring out the header files
in Makefiles is more trouble than it's worth.

> Also I have never tried gnu global. I need to check it out too. And
> again, if decided this helper is needed, I'll add gnu global too.

Really the simplest thing for gnu global is to just run 'gtags' in the
top level directory, and let it recursively handle all files it
understands. Having to run 'make gtags' is not much of a convenience!
;)

BR,
Jani.