cscope أو ctags لماذا تختار أحدهما على الآخر؟

Question

أستخدم vim / gvim بشكل أساسي كمحرر وأتطلع إلى استخدام مجموعة من lxr (المرجع الترافقي لنظام التشغيل Linux) وإما com.cscope أو com.cttags لاستكشاف مصدر النواة.ومع ذلك، لم أستخدم أيًا منهما على الإطلاق com.cscope أو com.cttags وأود أن أعرف لماذا قد يختار المرء واحدًا على الآخر مع الأخذ في الاعتبار استخدامي لـ vim كمحرر أساسي.

Answer 1

تمكن CTags ميزتين: مما يسمح لك بالقفز من مكالمات الدالة إلى تعريفاتهم، وإكمال OMNI. الأول يعني أنه عندما تكون عبر مكالمة إلى طريقة، تضرب g] أو CTRL-] سوف اقفز إلى المكان الذي يتم فيه تعريف هذه الطريقة أو تنفيذها. الميزة الثانية تعني أنه عند الكتابة foo. أو foo->, ، وإذا كانت Foo هيكل، فسيتم عرض قائمة منبثقة مع إكمال حقل.

cscope لديه أيضا الميزة الأولى - باستخدام set cscopetag - ولكن ليس آخر. ومع ذلك، تضيف CSCOPE بالإضافة إلى القضاء على أي من الأماكن التي يتم فيها استدعاء وظيفة أيضا.

بقدر ما تقصد القفز حول قاعدة التعليمات البرمجية، لن تقودك CTags فقط نحو المكان الذي تنفذ فيه الوظيفة حيث يمكن أن تظهر لك CSCOPE حيث يتم استدعاء وظيفة أيضا.

لماذا تختار واحدة على الآخر؟ حسنا، أنا استخدم كليهما. CTAGS أسهل لإعدادها، واسرعت تشغيلها وإذا كنت تهتم فقط بالقفز في إحدى الطرق، فسوف تظهر لك خطوط أقل. يمكنك فقط تشغيل :!ctags -R . و g] فقط يعمل. كما أنه يتيح أن Omni Complete thing.

cscope هو عظيم لقواعد كود أكبر غير معروفة. الإعداد هو ألم لأن CSCOPE يحتاج إلى ملف يحتوي على قائمة بأسماء الملفات لتحليلها. أيضا في VIM، بشكل افتراضي لا توجد ارتباطات رئيسية تم إعدادها - تحتاج إلى تشغيل :cscope blah blah يدويا.

لحل مشكلة قبضة لدي برنامج نصي باش cscope_gen.sh يبدو أن هذا:

#!/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

يبحث هذا عن الرمز الذي يهمني، بإنشاء قائمة cscope.files وإنشاء قاعدة البيانات. بهذه الطريقة يمكنني تشغيل ":! cscope_gen.sh" بدلا من الاضطرار إلى تذكر كل خطوات الإعداد.

أنا خريطة cscope البحث إلى ctrl-space x 2 مع هذا المقتطف، مما يخفف من داونر آخر من cscope:

nmap <C-@><C-@> :cs find s <C-R>=expand("<cword>")<CR><CR>

هناك هذا cscope_maps.vim البرنامج المساعد الذي يحدد مجموعة من الروابط مماثلة. لا أستطيع أبدا أن أتذكر ما يعنيه كل الخيارات، لذلك تميل إلى التمسك بمساحة CTRL.

إزاء الختام: CTAGS أسهل في الإعداد والمناسبة في الغالب دون القيام بالكثير، من الضروري إكمال OMNI أيضا. يوفر CScope المزيد من الميزات إذا كان عليك الحفاظ على قاعدة كود كبيرة ومعظما غير معروفة، ولكنها تتطلب المزيد من عمل الساق.

Answer 2

كنت في نفس الوضع منذ عدة أشهر ...

عدم وجود دقة CTAGS هو ألم في ..، وأجد سكوتا أفضل بكثير لجميع الأشياء ذات الصلة وحدات الماكرو (وهناك مجموعة من وحدات الماكرو في نواة Linux) ..

فيما يتعلق بالاستخدام، هذا واضح في الواقع ... لقد اكتبت فقط CSCOPE -R في جذر النواة الخاص بك، ثم لا تقلق بشأن ذلك .. (أعني ما إذا كنت تريد فقط استكشاف هذا مثالي ...)

بعد ذلك، تعتمد جميع الارتباطات الرئيسية على CTRL- (يمكنك إعادة استخدامها إذا كنت تعاني من حساسية من CTRL)، فأنت تستخدم أساسا S و G ....

تطوير النواة، لم أكن بحاجة إلى الكثير من الانتهاء ....

على أي حال، انتقل ل cscope، هذا أكثر ملاءمة، دقيقة.

Answer 3

همم...ربما يجب عليك استخدام علامات etags بدلاً من علامات ctag ...

إذا كنت تستخدم cscope، فيمكنك رؤية سلاسل الاتصال، أي من يستدعي هذه الوظيفة وما هي الوظائف التي تستدعيها هذه الوظيفة؟

لست متأكدًا مما إذا كان من الممكن القيام بذلك باستخدام etags/ctags...

تلك ميزة واحدة فقط..ماذا عن معرفة الملف الذي يحتوي على تعريف وظيفة معينة؟هذا تحصل عليه فقط في cscope.

أنا أستعمل كلاهما cscope وetags، كلاهما جيد لأشياء مختلفة، خاصة عند العمل مع قاعدة تعليمات برمجية كبيرة، مثل Linux Kernel.في الواقع، لقد بدأت في استخدام cscope وetags عندما بدأت العمل مع Linux Kernel/Xen.

LXR ليس رائعًا، لأنه يتعين عليك النقر والتنقل عبر الشبكة وما إلى ذلك، بينما يمكنك إنشاء قواعد بيانات cscope وtags على كود kernel الخاص بك و لم يكن لديك للذهاب عبر الشبكة (على عكس lxr).

Answer 4

أقترح استخدام GTAGS Global. يمكن استخدام البرنامج المساعد VIM gen_tags. لدمج gtags مع vim.