J'utilise principalement vim / gvim comme éditeur et je cherche à utiliser une combinaison de lxr (la référence croisée Linux) et de cscope ou de ctags pour explorer la source du noyau. Cependant, je n'ai jamais utilisé ni cscope ni ctags et j'aimerais savoir pourquoi on pourrait choisir l'un plutôt que l'autre en tenant compte de mon utilisation de vim en tant qu'éditeur principal.
ctags active deux fonctionnalités: vous permettant de passer des appels de fonction à leurs définitions et l'achèvement omni. Le premier signifie que lorsque vous êtes sur un appel à une méthode, frapper g]ou CTRL-]va sauter à l'endroit où cette méthode est définie ou implémentée. La deuxième caractéristique signifie que lorsque vous tapez foo.ou foo->, et si foo est une structure, un menu contextuel avec complétion de champ sera affiché.
cscope a également la première fonctionnalité - utiliser set cscopetag- mais pas la dernière. Cependant, cscope ajoute également la possibilité de sauter à n'importe quel endroit où une fonction est également appelée.
Donc, pour ce qui est de sauter dans une base de code, les ctags ne vous mèneront jamais que vers l'endroit où la fonction est implémentée, tandis que cscope peut vous montrer où une fonction est également appelée.
Pourquoi choisiriez-vous l'un plutôt que l'autre? Eh bien, j'utilise les deux. ctags est plus facile à configurer, plus rapide à exécuter et si vous ne vous souciez que de sauter dans un sens, il vous montrera moins de lignes. Vous pouvez simplement courir :!ctags -R .et fonctionne g]simplement. Il permet également cette chose omni complète.
Cscope est idéal pour les bases de code plus grandes et inconnues. La configuration est pénible car cscope a besoin d'un fichier contenant une liste de noms de fichiers à analyser. De plus, dans vim, par défaut, aucune liaison de touches n'est configurée - vous devez exécuter :cscope blah blahmanuellement.
Pour résoudre le premier problème, j'ai un script bash cscope_gen.shqui ressemble à ceci:
#!/bin/sh
find . -name '*.py' \
-o -name '*.java' \
-o -iname '*.[CH]' \
-o -name '*.cpp' \
-o -name '*.cc' \
-o -name '*.hpp' \
> cscope.files
# -b: just build
# -q: create inverted index
cscope -b -q
Cela recherche le code qui m'intéresse, crée la liste cscope.files et crée la base de données. De cette façon, je peux exécuter ":! Cscope_gen.sh" au lieu d'avoir à me souvenir de toutes les étapes de configuration.
Je mappe la recherche cscope sur ctrl-space x 2 avec cet extrait de code, ce qui atténue l'autre downer de cscope:
nmap <C-@><C-@> :cs find s <C-R>=expand("<cword>")<CR><CR>
Il y a ce plugin cscope_maps.vim qui met en place un tas de liaisons similaires. Je ne me souviens jamais de ce que signifient toutes les options, alors j'ai tendance à m'en tenir à ctrl-space.
Donc pour conclure: les ctags sont plus faciles à mettre en place et fonctionnent la plupart du temps sans faire grand chose d'autre, c'est aussi vital pour l'omni-complet. cscope fournit plus de fonctionnalités si vous devez maintenir une base de code volumineuse et pour la plupart inconnue, mais nécessite plus de travail.
make tagsdans le répertoire racine du noyau et j'ai joué à sauter et la plupart du temps, je me suis retrouvé au mauvais endroit. J'ai lu que ctags a des problèmes avec le préprocesseur c, mais étant donné que ctags est utilisé dans lxr, il doit évidemment y avoir quelque chose qui peut être fait.cscopetag(cst) pour que les commandes:tagetCTRL-]recherchent d'abord dans cscope, puis dans les balisesg C-], vim vous montrera la liste des balises correspondant au nom. Vous devrez toujours trouver la définition appropriée que vous recherchez manuellement.J'étais dans la même situation il y a quelques mois ...
Le manque de précision des ctags est pénible dans un .., et je trouve que cscope est bien meilleur pour tous les trucs liés aux macros (et il y a un tas de macros dans le noyau Linux) ..
concernant l'utilisation, c'est en fait simple ... il vous suffit de taper cscope -R à la racine de votre noyau et ensuite vous n'avez rien à craindre ... (je veux dire si vous voulez juste explorer c'est parfait ...)
Ensuite, les raccourcis clavier sont tous basés sur Ctrl- \ (vous pouvez le remapper si vous êtes allergique à Ctrl), vous utilisez principalement s et g ....,
En développant pour le noyau, je n'avais pas tellement besoin de l'achèvement ...
Quoi qu'il en soit, optez pour cscope, c'est beaucoup plus pratique, précis.
la source
Hmm ... Vous devriez probablement utiliser etags au lieu de ctags ...
Si vous utilisez cscope, vous pouvez voir les chaînes d'appels, c'est-à-dire qui appelle cette fonction et quelles fonctions cette fonction appelle-t-elle?
Je ne sais pas si cela peut être fait en utilisant etags / ctags ...
C'est juste une fonctionnalité ... qu'en est-il de trouver le fichier qui contient une définition de fonction particulière? Ce que vous obtenez uniquement dans cscope.
J'utilise à la fois cscope et etags, ils sont tous les deux bons pour différentes choses, en particulier lorsque vous travaillez avec une grande base de code, comme le noyau Linux. En fait, j'ai commencé à utiliser cscope et etags lorsque j'ai commencé à travailler avec Linux Kernel / Xen.
LXR n'est pas génial, car vous devez cliquer, passer sur le réseau, etc., alors que vous pouvez construire les bases de données cscope et balises sur le code de votre noyau et n'avez pas à passer par le réseau (contrairement à lxr).
la source
Suggérer d'utiliser des gtags globaux. Pourrait utiliser le plugin vim gen_tags pour intégrer des gtags avec vim.
la source