Создание дерева вызовов из базы данных cscope

Я хочу генерировать полные и частично вызывающие деревья из базы данных cscope проектов c и С++ в Linux.

Проект довольно большой, поэтому работать с полным деревом вызовов проекта может быть непросто, поэтому я хочу ограничить создание дерева вызовов с помощью grep-like фильтра имен функций.

А также я хочу иметь возможность создавать "вызываемые" и "вызываемые из" поддеревьев из любой точки.

Таким образом, инструмент должен быть интерактивным и простым для исправления.

PS: Я хочу использовать базу данных cscope, потому что она уже используется в проекте, и ее генерация довольно быстро. Я использую редактор vim и имею систему X окон.

В sourceforge есть программа cbrowser, но ее функция call-tree (callgraph) сломана.

Ответ 3

Мне не известны никакие программы, кроме cscope, которые читают базы данных cscope. Даже функция vim cstag запускает только процесс cscope, который он запрашивает.

Что касается генерации диаграммы вызовов, если вы не возражаете выйти за пределы cscope, мне больше нравится то, что создает doxygen. Они могут быть немного большими, но также генерируют график почти из всех точек, и невероятно легко просматривать источник непосредственно в нем.

Ответ 4

kscope может быть другой опцией. Я не уверен, будет ли это делать все, но это довольно универсально для графического интерфейса.

Пользователям Ubuntu, у которых возникли проблемы с его запуском, рекомендуется следовать этим инструкциям.

Ответ 5

Я получил этот Bash script на основе cscope для работы в Cygwin и Windows: http://toolchainguru.blogspot.com/2011/03/c-calltrees-in-bash-revisited.html

См. пример вызова "graph" (я называл это вызовом "tree", whoops). См. пример из ядра Linux.

Требуется cscope (конечно) и graphviz. Он способен выполнять графики вверх и вниз, а также комбинированные вверх и вниз графики (см. Пример).

Я не продемонстрировал его здесь, но этот метод работает очень хорошо на больших проектах, где одна и та же функция может быть определена в нескольких каталогах. Для одного и того же имени функции будет только один node (поэтому один "главный" node, даже если у вас есть несколько main(), определенных в структуре вашего каталога) --- и у вас будет несколько ребер, исходящих из таких a node, с индикаторами файлов/строк. Я нашел этот аспект более полезным, чем GNU cflow, который настаивал на выборе только одного каталога для поиска. (Jason Nyberg Bash script as is не очень хорошо работает с потоковой обработкой, который GNU cflow обрабатывает красиво; иметь в виду.)