Hi, > First of all, I'm thinking about implementing the nofollow option for gtags, > as > proposed on [2]. My question is, how exactly should this behave: should that > only omit symbolic links that point to a directory or should that ignore > symbolic links completely (e.g. ./foo.c pointing to ./bar.c) ?
I have not thought about details yet. Is there something proposal? > When thinking about it and looking into the code, I don't quite understand the > following part of find_read_traverse() (libutil/find.c): ... > To be specific, what's the purpose of lines 539-551? If I'm not mistaken, the > test at line 545 can never succeed because it is the opposite of the test at > line 538. It might be so. But at present, this code is harmless. > Next, is there any benefit of determining the type of a file in getdirs() > function (I mean prefixing the filename with f,d) instead of determining = > the > type directly in the find_read_traverse() function? This is due to a historical reason. In some systems like BSD, dirent structure has a member named 'd_type' which describes file type. Determining type by it, we can avoid to calling stat(2) for each files. But another systems like GNU/Linux doesn't has it. I wanted to hide the difference in a basic function, getdirs(). By the way, GLOBAL doesn't use the 'd_type' currently due to the following bug: [http://lists.gnu.org/archive/html/bug-global/2003-08/msg00002.html] > And finally: what actually made me start thinking about this is fact that > gtags > can not treat recursive links, like in [3]. This actually makes it difficult > to > use gtags on directories created by quilt setup, because quilt creates exactly > this type of directory structure (for a good reason). This could be worked > around by the nofollow option, but IMHO the recursive link detection should be > done also in default mode - what do you think? What is quilt setup? What should GLOBAL do? -- Shigio YAMAGUCHI <[email protected]> PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 _______________________________________________ Bug-global mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-global
