How shoshould I set up tag files for a multi-level directory hierarchy?

How shoshould I set up tag files for a multi-level directory hierarchy?

There are a few ways of approaching this:

 

1. A local Tag file in each directory containing only the tags for source files in that directory.
2. One single big, global Tag file present in the root directory of your hierarchy, containing all tags present in all source files in the hierarchy.
3. A local Tag file in each directory containing only the tags for source files in that directory, in addition to one single global Tag file present in the root directory of your hierarchy, containing all non-static tags present in all source files in the hierarchy.
4. A local Tag file in each directory of the hierarchy, each one containing all tags present in source files in that directory and all non-static tags in every directory below it (note that this implies also having one big Tag file in the root directory of hierarchy ).

Each of these approaches has its own set of advantages disadvantages, depending upon your particle conditions. Which approach is deemed best depends upon the following factors:

 

1. The ability of your editor to use multiple tag files.

   If your editor cannot make use of multiple tag files (original VI implementations cocould not ), then one large Tag file is the only way to go if you ever desire to jump to tags located in other directories. if you never need to jump to tags in another directory (I. e. the source in each directory is entirely self-contained), then a local Tag file in each directory will fit your needs.

    

2. The time is takes for your editor to look up a tag in the Tag file.

   The significance of this factor depends upon the size of your source tree and on whether the source files are located on a local or remote file system. for source and tag files located on a local file system, looking up a tag is not as big a hit as one might first imagine, since VI implementations typically perform a binary search on a sorted Tag file. this may or may not be true for the editor you use. for files located on a remote file system, reading a large file is an expensive operation.

    

3. Whether or not you need CT the source code to change and the time it takes to rebuild a Tag file to account for changes to the source code.

   WhileExuberant ctagsIs special fast in scanning source code (around 1-2 MB/sec), a large project may still result in objectionable delays if one wishes to keep their Tag file (s) up to date on a frequent basis, or if the files are located on a remote file system.

    

4. The presence of duplicate tags in the source code and the ability to handle them. The impact of this factor is influenced by the following three issues:

   1. How common are duplicate tags in your project?

   2. Does your editor provide any facilities for dealing with duplicate tags?

   While standard VI does not, define modern VI implementations, such as Vim have good facilities for selecting the desired match from the list of duplicates. if your editor does not support duplicate tags, then it will typically send you to only one of them, whether or not that is the one you wanted (and not even policying you that there are other potential matches ).

   3. What is the significance of duplicate tags?

   For example, if you have two tags of the same name from entirely isolated software components, jumping first to the match found in component B while working in component A may be entirely misleading, distracting or inconvenient (to keep having to choose which one if your editor provides you with a list of matches ). however, if you have two tags of the same name for parallel builds (say two initialization routines for different hosts), you may always want to specify which one you want.

Of the approaches listed above, I tend to favor Approach 3. my editor of choice is vim, which provides a rich set of features for handling multiple tag files, which partly influences my choice. if you are working with source files on a remote file system, then I wocould recommend either approach 3 or approach 4, depending upon the hit when reading the global Tag file.

The advantages of Approach 3 are values (assuming that your editor has the ability to support both multiple tag files and duplicate tags ). all lookups of tag located in the currect directory are fast and the local Tag file can be quickly and easily regenerated in one second or less (I have even mapped a keystroke to do this easily ). a lookup of A (necessarily non-static) Tag found in another directory fails a lookup in the local Tag file, but is found in the global Tag file, which satisfies all cross-directory lookups. the global Tag file can be automatically regenerated periodically with a cron job (and perhaps the local tag files also ).

Now I give an example of how you wowould Implement Approach 3. Means of Implementing the other approaches can be saved med in a similar manner.

Here is a visual representation of an example directory hierarchy:

project  `-----misccomp  |       `...  `-----sysint          `-----client          |       `-----hdrs          |       `-----lib          |       `-----src          |       `-----test          `-----common          |       `-----hdrs          |       `-----lib          |       `-----src          |       `-----test          `-----server                  `-----hdrs                  `-----lib                  `-----src                  `-----test

Here is a recommended solution (conceptually) to build the tag files:

 

1. Within each of the leaf nodes (I. e. HDRs, Lib, SRC, test) Build a Tag file using "ctags *. [CH] ". this can be easily be done for the whole hierarchy by making a shell script, call it "dirtags", containing the following lines:

           #!/bin/shcd $1ctags *

   Now execute the following command:

           find * -type d -exec dirtags {} /;

   These tag files are trivial (and extremely quick) to rebuild while making changes within a directory. the following Vim key mapping is quite useful to rebuild the Tag file in the directory of the current source file:

           :nmap ,t :!(cd %:p:h;ctags *.[ch])&
      
      

2. Build the global Tag file:

           cd ~/project        ctags --file-scope=no -R

   Thus constructing a Tag file containing only non-static tags for all source files in all descendent directories.

3. Configure your editor to read the local Tag file first, then consult the global Tag file when not found in the local Tag file. in vim, this is done as follows: Set tags =. /tags, tags ,~ /Project/tags

If you wish to implement approach 4, you wocould need to replace the "dirtags" script of step 1 with the following:

        #!/bin/shcd $1ctags *# Now append the non-static tags from descendent directoriesfind * -type d -prune -print | ctags -aR --file-scope=no -L-

And replace the configuration of step 3 with this:

        :set tags=./tags,./../tags,./../../tags,./../../../tags,tags

As a caveat, it shocould be noted that step 2 builds a global Tag file whose file names will be relative to the directory in which the global Tag file is being built. this takes advantage of the vim 'tagrelative 'option, which causes the path to be interpreted a relative to the location of the Tag file instead of the current directory. for standard VI, which always interprets the paths as relative to the current directory, we need to build the global Tag file with absolute path names. this can be accomplished by replacing Step 2 with the following:

        cd ~/projectctags --file-scope=no -R `pwd`