cscope ou ctags pourquoi choisir l’un sur l’autre?

J’utilise principalement vim / gvim en tant qu’éditeur et j’utilise une combinaison de lxr (Linux Cross Reference) et de cscope ou ctags pour explorer les sources du kernel. Cependant, je n’ai jamais utilisé ni cscope ni ctags et j’aimerais savoir pourquoi on pourrait en choisir un en tenant compte de mon utilisation de vim en tant qu’éditeur principal.

ctags permet deux fonctionnalités: vous permettre de passer des appels de fonction à leurs définitions, et l’achèvement omni. Le premier signifie que lorsque vous passez un appel à une méthode, si vous appuyez sur g] ou CTRL-] passerez directement à l’endroit où cette méthode est définie ou implémentée. La deuxième fonctionnalité signifie que lorsque vous tapez foo. ou foo-> , et si foo est une structure, alors un menu contextuel avec achèvement du champ sera affiché.

cscope a également la première fonctionnalité – en utilisant set cscopetag – mais pas la dernière. Cependant, cscope ajoute la possibilité de sauter à n’importe quel endroit où une fonction est appelée.

Donc, en ce qui concerne les sauts de code, les ctags ne vous mèneront que vers l’endroit où la fonction est implémentée, alors que cscope peut vous montrer où une fonction est appelée.

Pourquoi choisiriez-vous l’un sur l’autre? Eh bien, j’utilise les deux. ctags est plus facile à configurer, plus rapide à exécuter et si vous ne voulez que sauter d’une manière, cela vous montrera moins de lignes. Vous pouvez simplement lancer :!ctags -R . et g] fonctionne juste. Cela permet aussi cette chose 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 à parsingr. Toujours dans vim, par défaut il n’y a pas de raccourcis clavier configurés – vous devez lancer :cscope blah blah manuellement.

Pour résoudre le premier problème, j’ai un script bash cscope_gen.sh qui 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 firebase database. De cette façon, je peux lancer “:! Cscope_gen.sh” au lieu de devoir mémoriser toutes les étapes de configuration.

Je mappe la recherche cscope sur ctrl-space x 2 avec cet extrait, ce qui atténue l’autre élément négatif de cscope:

 nmap  :cs find s =expand("") 

Il y a ce plugin cscope_maps.vim qui met en place un tas de liens similaires. Je ne peux jamais me rappeler ce que toutes les options signifient, donc ont tendance à coller à ctrl-espace.

Donc, pour conclure: ctags est plus facile à configurer et fonctionne surtout sans faire grand chose, il est vital aussi pour les omni-complets. cscope fournit plus de fonctionnalités si vous devez maintenir une base de code volumineuse et la plupart du temps inconnue, mais nécessite plus de travail sur les jambes.

J’étais dans la même situation il y a quelques mois …

Le manque de précision des ctags est un problème dans un .., et je trouve cscope beaucoup mieux pour toutes les macros liées (et il y a un tas de macros dans le kernel Linux).

en ce qui concerne l’utilisation, c’est en fait simple … vous tapez simplement cscope -R à la racine de votre kernel et vous n’avez plus à vous soucier de rien.

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éveloppement pour le kernel, je n’ai pas eu besoin de l’achèvement …

Quoi qu’il en soit, optez pour cscope, c’est beaucoup plus pratique et précis.

Hmm … Tu devrais 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 caractéristique … Qu’en est-il de trouver le fichier qui contient une définition de fonction particulière? Cela vous obtenez seulement dans cscope.

J’utilise à la fois cscope et etags, ils conviennent tous deux à différentes choses, en particulier lorsque vous travaillez avec une base de code volumineuse, telle que le kernel Linux. En fait, j’ai commencé à utiliser cscope et etags quand j’ai commencé à travailler avec le kernel Linux / Xen.

LXR n’est pas génial, car vous devez cliquer, parcourir le réseau, etc., alors que vous pouvez créer les bases de données cscope et tags sur votre code kernel sans avoir à passer par le réseau (contrairement à lxr).