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

[Yuri Volchkov <yuri.volchkov@gmail.com>]

Jani Nikula <jani@nikula.org> writes:

> 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.
Well, for my needs kernel tags doing pretty good job. Partially because
I use helm-git-grep whenever I need project-wide refactoring.

But I agree, that machinery for building index is way too complicated in
the kernel. That's why I said "not too ugly".
>
>> 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!
> ;)

I feel convinced. Just forget about this patch.
>
> BR,
> Jani.