icheck - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

icheck - перевірка ABI/API інтерфейсу C

СИНТАКСИС

я перевіряю -- канонізувати [[--базова лінія Фото] ...] [ВАРІАНТИ] [GCC_OPTIONS] [--] файли

я перевіряю --порівняти [ВАРІАНТИ] старий_файл новий_файл

ОПИС

Інструмент для статичної перевірки інтерфейсів C на наявність змін API та ABI. Усі зміни типу
декларації, які можуть спричинити зміни ABI, повинні бути виявлені разом із більшістю змін API.

icheck призначений для використання з бібліотеками як метод запобігання дрейфу ABI.

КОМАНДИ

Зменште набір вихідних файлів до канонічного файлу інтерфейсу за допомогою --canonify, а потім порівняйте
два таких файли інтерфейсу з --compare. Якщо між ними є зміни інтерфейсу,
icheck опише зміни і не вдасться.

-- канонізувати [[--базова лінія Фото] ...] [ВАРІАНТИ] [GCC_OPTIONS] [--] файли

Каноніфікуйте файли вихідного коду (як правило, заголовки .h) для порівняння пізніше
--порівняти. Зазвичай використовується з -o можливість зберегти підсумок у файлі.

--порівняти [ВАРІАНТИ] старий_файл новий_файл

Читає два канонічні файли інтерфейсу, створені за допомогою -- канонізувати і порівнює
структуру вихідного коду до змін у загальнодоступному інтерфейсі програми
(інтерфейс розробника або API) і двійковий інтерфейс програми (ABI), який використовувався
посилання на інші програми чи бібліотеки.

ВАРІАНТИ

Я ПЕРЕВІРЮ ВАРІАНТИ
-o, - вихід Фото

Надсилайте вихід у FILE, а не в стандартний вихід.

--відлагоджувати N

Дамп налагоджувальної інформації.

--тільки ЧОГО

Обробляйте лише дану РЕЧ.

--пропустити-з Фото

Відмовтеся від непотрібних речей Фото.

--пропустити-з-пере RegExp

Пропускати непотрібні речі з файлів, що відповідають регулярному виразу.

--тільки-від Фото

Беріть лише речі з Фото.

--тільки-від-ре RegExp

Беріть лише файли, які відповідають регулярному виразу.

GCC_OPTIONS

GCC_OPTIONS передаються до gcc -E

ДОПОМОГТИ ВАРІАНТИ
--допомога
Відобразити синопсис довідки для я перевіряю.

ПРИКЛАДИ

Усі вихідні файли попередньо обробляються за допомогою gcc, тому canonify потребує такої ж інформації про включення
як вихідний код - дотримуйтесь синтаксису з Makefile, щоб включити параметри -I до cpp (Або
ПКУ), щоб можна було знайти всі необхідні заголовки. я перевіряю перерве, якщо потрібно
заголовки не знайдено. Джерело має бути компілюваним; icheck не може обробляти файли, які
неможливо безпосередньо зібрати. Якщо в заголовку відсутні оператори #include або в іншому випадку
вимагає використання особливим чином, тоді його неможливо обробити безпосередньо за допомогою icheck.
Замість цього напишіть заглушок C-файл, який налаштовує все належним чином, а потім #включає файл
заголовка.

я перевіряю -- канонізувати -o ~/icheck/стара версія -I/usr/include/foo-2.0 /usr/src/bar/src/foobar.h

Підготуйте текстовий підсумок файлу foobar.h та всіх файлів, які він містить. Підсумок є
виписано до ~/icheck/стара версія. Повторіть для /usr/src/bar1/src/foobar.h - той самий файл
у новішому вихідному каталозі, виводячи до нового файлу, напр ~/icheck/нова версія.

я перевіряю --порівняти -o ~/icheck/results.txt ~/icheck/стара версія ~/icheck/нова версія

Записує звіт про порівняння двох підсумкових файлів. У звіті зазначено все
зміни в ABI та/або API, виявлені під час порівняння.

я перевіряю -- канонізувати -o debian/icheck.canonical -Idebian/foo-dev/usr/include debian/foo-
dev/usr/include/foobar.h

я перевіряю --порівняти debian/icheck.manifest debian/icheck.canonical

Ці два твердження, включені в а debian/правила файл, призведе до створення пакету
не вдається, якщо API або ABI змінилися несподівано, де icheck.manifest є копією
очікуваний інтерфейс, що входить у пакет.

Зауважте, що аргументи --compare самі є дійсними файлами C, які попередньо обробляються,
тому icheck.manifest може містити логіку препроцесора C. Це може бути корисно, коли пакет
експортує різні інтерфейси залежно від архітектури хоста. У цьому випадку не можна
замініть його на нову копію icheck.canonical, коли інтерфейс зміниться і вам це потрібно
оновити маніфест. Замість того, щоб оновлювати весь маніфест вручну, покладіть руку-
написані описи інтерфейсу в одному файлі (icheck.static-маніфест), а потім використовуйте:

я перевіряю -- канонізувати --базова лінія debian/icheck.static-маніфест -o debian/icheck.dynamic-
проявляється

Нарешті, створіть icheck.manifest, що містить:
#include "icheck.static-manifest"
#include "icheck.dynamic-manifest"
Це дозволяє оновлювати деякі частини маніфесту вручну, при цьому автоматично
генеруючи решту.

ВИХІД

icheck генерує розгорнутий опис кожної можливої ​​зміни API або ABI на основі типу
інформації. Він не досліджує фактичний програмний код, тому це можливо
деякі зміни типу, які він виявляє, не є фактичними змінами ABI або API. Однак це нормально
відбувається лише тоді, коли програмний код був явно написаний для цього. Якщо сумніваєтеся, припустите, що так
змінено.

Наприкінці icheck надає підсумок змін. Зауважте, що тут є вказівки
залежить від порядку аргументів для --compare: попередній інтерфейс має бути першим,
або напрямки будуть навпаки. Значення різних термінів як
наступним чином:

ABI ABI сумісна, якщо речі скомпільовані для однієї версії
інтерфейс працюватиме під час використання іншої версії.

API. API сумісний, якщо все скомпільовано для однієї версії
інтерфейс може бути скомпільований проти іншого.

форвард-сумісний
Інтерфейс є сумісним із пересиланням, якщо все скомпільовано проти старого
версія буде працювати з новою. Це важлива особливість для soname
зміни.

зворотно сумісний
Інтерфейс є зворотно сумісним, якщо щось скомпільовано відповідно до нового
версія буде працювати зі старою. Це важлива особливість для шлібс
версія зміни. Якщо ви не створюєте пакунки Debian, можливо, цього не робите
піклуватися про зміни, які не є зворотною суміністю.

Використовуйте icheck онлайн за допомогою служб onworks.net