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

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

to Jani:

>> What's the point in adding these to configure? Or, to be honest, to the
>> build at all?
Ok, modifying configure was probably unnecessary.

>> I guess I'm also biased because I use gnu global [1] instead. And for
>> that I have a script of my own that basically boils down to:
>>
>> $ 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.

>> 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.

to Tomi:

> I agree with Jani about configure and build steps, but could tolerate
> convenience goals like `cscope` and `tags` (and something `global` !)
> which would build corresponding files for developers to utilize (provided
> those are accurate enough, we don't want to lessen general quality (from
> what it is now) of the system due to too bad quality tags files
> (content-wise)...

Sorry, I did not get what is accurate enough, what is lessen quality and
what is too bad? Could you please explain a little more detailed?

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.