Отслеживание изменений публичного API C ++ lib

Question

В настоящее время я работаю над большим проектом на основе C ++ Qt, который собирается перейти под существенный пересмотр своего открытого API, и было бы неплохо иметь инструмент, который может генерировать отчет о том, какие методы были добавленыили удален из сборки для сборки.

Я знаю, что для Java есть инструмент для этого, и я думаю, что может быть один для .NET, но я не смог, после небольшого поиска, найти что-нибудь для C ++.

Существует ли один.Кроссплатформенность была бы хороша, или если бы только в Linux это тоже было бы хорошо.

Answer 1

Если вы используете Doxygen или какой-либо подобный инструмент для документирования своего API, вы можете diff оглавление.

• Это то, что вы должны делать в любом случае.
  • (Вы также можете указать Doxygen найти недокументированные функции.)
• Вы можете легко применить его к древним чеинам, ничего не меняя.
• Doxygenи его родные знают достаточно о языке, чтобы быть чувствительными к private и public.
• Это решение может быть применено ко многим языкам и не зависит от конкретной IDE.
• Неттребуется стороннее программное обеспечение (если у вас уже есть генератор документации).

Answer 2

Проверьте нижнюю часть коммерческого списка на apidiff, я думаю, что это будет ближайший матч.

Предложение использования 'nm' неплохое, вы можете запустить

nm <binary_or_lib> | c++filt

И он создаст приличный снимок, который потребует значительного количества постобработки.

Есть много способов накатить свой собственный на этот:

1. Doxygen может сгенерировать XML-файл, содержащий всю информацию о классе / элементе / методе, которую вы затем можете получить для построения деревьев классов. Тогда это будет вопрос сравнения деревьев. Некоторые полезные сценарии / утилиты постобработки можно найти @ http://www.doxygen.nl/helpers.html

2. Если вы компилируете с помощью gcc, egypt - это новый подход, использующий промежуточный RTL для создания графиков зависимости от вызовов - кажется, что это не так Может быть, трудно использовать аналогичный метод для генерации базовой информации API.

3. GCC-XML будет генерировать XML-представления скомпилированного кода, немного более низкого уровня, чем Doxygen, поскольку он предоставляет механизм для написания кода-оболочки.

4. cppHeaderParser , модуль python будет генерировать красивые представления заголовков объектов python, предоставляя простой способ генерации карт API.

5. ctags создает базу данных тегов, которая, вероятно, может быть обработана. У него проблемы с пространствами имен C ++.

Некоторые коммерческие решения

1. scitool's Понимание отлично справляется с картированием программного обеспечения и имеет Perl API для запросов к своей базе данных.

2. MagicDraw является своего рода тяжеловесным инструментом, сконцентрированным на UML, но он может реконструировать существующую кодовую базу C ++ и генерировать метаинформацию.

3. apidiff представляется довольно доступным инструментом, и, учитывая критерии (кроссплатформенный, C ++), вероятно, ближайший соответствует.

Answer 3

Вместо того, чтобы разрешить всем видимым символам экспортировать из вашей библиотеки автоматически, вы можете использовать явный список экспортируемых символов.Для больших библиотек это даже рекомендуется.

В Windows вы используете файл .DEF для экспорта символов из DLL.

В Unix-подобных вы используетескрипт компоновщика для этого.

Answer 4

Попробуйте Abi-Compliance-Checker . Этот инструмент показывает добавленные / удаленные символы в вашем API, изменения параметров / типов данных и другие изменения с точки зрения двоичной совместимости. Это кроссплатформенный. Наилучшая производительность в Linux, но она может работать и на Windows и Mac.

Использование:

abi-compliance-checker -lib NAME -old OLD.abidump -new NEW.abidump

*. Abidump файлы - это дампы ABI, сгенерированные инструментом abi-dumper .

Эта таблица совместимости для библиотеки Qt создается с помощью этого инструмента:

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

Answer 5

Добавить шаг автоматической сборки, который использует nm для Unix-лайков и любого другого инструмента Windows (dumpbin?) Для вывода списка экспортируемых функций. Используйте некоторый язык сценариев, чтобы убрать неважные биты, которые меняются от сборки к сборке, например адреса.

После каждой сборки фиксируйте этот файл для контроля версий. Затем вы можете увидеть отличия от каждой сборки.

Поскольку это приложение C ++, имена также будут отслеживать изменения типа параметра.

Answer 6

В дополнение к возможности использования Doxygen для развертывания собственного инструмента анализа, я бы также предложил изучить BSC Toolkit .Это позволяет получить доступ к информации о браузере кода / класса, сгенерированной компиляторами MS, и доступна бесплатно.Инструментарий обеспечивает программный доступ ко всем определениям, ссылкам на использование, номерам источников и строк, параметрам, модификаторам доступа и т. Д. Имена предоставляются в их искаженной форме, а также включены средства для перевода их в читаемый человеком формат при необходимости.

Вот некоторые основные выводы проекта, над которым я работаю:

IXConnection (struct_name)
IXConnection::STATE (enum_name)
IXConnection::setState(enum STATE) (mem_func public)
IXConnection::setAccount(struct IXAccount *) (mem_func public)
IXConnection::setDisplayName(class String *) (mem_func public)
IXConnection::setProtocolData(void *) (mem_func public)
IXConnection::getState(enum STATE *) (mem_func public)
IXConnection::getAccount(struct IXAccount * *) (mem_func public)
IXConnection::getProtocol(struct IXProtocol * *) (mem_func public)
IXConnection::getPassword(class String * *) (mem_func public)
IXConnection::getDisplayName(class String * *) (mem_func public)
IXConnection::getProtocolData(void * *) (mem_func public)
IXConnection::setProgress(class String *,int,int) (mem_func public)
IXConnection::notice(class String *) (mem_func public)
IXConnection::error(enum REASON,class String *) (mem_func public)

Answer 7

Если вы используете git, вы должны создать новую ветку и использовать скрипт оболочки для сравнения всех заголовочных файлов, которые определяют API между ветвями.Если вы еще этого не сделали, вам следует использовать шаблон impl для заголовочных файлов API, чтобы сделать двоичную библиотеку совместимой / более стабильной для будущих версий.Смотрите запись для d_pointer в вики Qt для разработчиков или часть о D-Pointers в технической базе KDE.