In the case of an already developed code - say a stable library - there isn't any need for the mechanism that I mentioned. But for a large project, specially not managed in a single place, with arbitrary updations, this *might* help; and building and tag generation go hand-in-hand.
I would like to see this just as intutive as Make concept is; as meaningful as make is used in small projects. Compiling a dozen files doesn't take much time, but Make is rather used for ease of management.
Well, I'm not insisting this way of tag generation of course, but just thinking loud whether such a mechanism already exists. Yes, it's a question of how you want to manage it? :D
Sounds more trouble than its worth to me Jeenu. ctags is fast, andOn 1/15/08, Jeenu V <email@example.com> wrote:
> I have been trying to manage the ctags for C projects with a Makefile. I
> plan to do something like this: Generate the ctags file for a particular
> source file at a next step of compilation or a separate step so that, there
> would be a separate tag file for each .c file, just like a .o object file.
> Now what I want to achieve is to combine these individual tag files to the
> final one, in the same way .o files are linked to make the final obj file
> I feel this is a good way to keep the tag file in sync with the whole
> project, instead of scanning whole of .c files to build the main tag file.
> When I referred the man page, I couldn't find any of this kind. Is there an
> existing option for this? or a better one?
unless your projects are very large, it does take much for it to scan
a whole source tree with the -R switch. If your projects contain html
doc, restrict ctags to a given language to avoid indexing the html for
example, and use excludes to prune dirs not to be indexed, and that's
What you are proposing to do sounds complex and goes against the grain
IMHO. More experienced ctags users might have a different opinion