icheck — online w chmurze

PROGRAM:

IMIĘ

icheck - narzędzie do sprawdzania ABI/API interfejsu C

STRESZCZENIE

sprawdzam --kanonizować [[--linia bazowa FILE] ...] [OPCJE] [GCC_OPTIONS] [--] pliki

sprawdzam --porównywać [OPCJE] stary_plik nowy plik

OPIS

Narzędzie do statycznego sprawdzania interfejsów C pod kątem zmian API i ABI. Wszystkie zmiany typu
deklaracje, które mogą powodować zmiany ABI, powinny zostać wykryte wraz z większością zmian API.

icheck jest przeznaczony do użytku z bibliotekami, jako metoda zapobiegania dryfowi ABI.

POLECENIA

Zredukuj zestaw plików źródłowych do kanonicznego pliku interfejsu za pomocą opcji --canonify, a następnie porównaj
dwa takie pliki interfejsu z opcją --compare. Jeśli występują między nimi zmiany interfejsu,
icheck opisze zmiany i zakończy się niepowodzeniem.

--kanonizować [[--linia bazowa FILE] ...] [OPCJE] [GCC_OPTIONS] [--] pliki

Kanonifikuj pliki kodu źródłowego (zwykle nagłówki .h), które będą później porównywane
--porównywać. Zwykle używany z -o możliwość zapisania podsumowania do pliku.

--porównywać [OPCJE] stary_plik nowy plik

Odczytuje dwa kanoniczne pliki interfejsu wygenerowane za pomocą --kanonizować i porównuje
struktury kodu źródłowego do zmian w Publicznym Interfejsie Aplikacji
(interfejs programisty lub API) oraz interfejs binarny aplikacji (ABI).
łącza z innymi programami lub bibliotekami.

OPCJE

SPRAWDZAM OPCJE
-o, --wyjście FILE

Wysyłaj dane wyjściowe do PLIKU, a nie na standardowe wyjście.

--odpluskwić N

Zrzuć informacje o debugowaniu.

--tylko RZECZ

Przetwarzaj tylko daną RZECZ.

--pomiń-z FILE

Pomiń niepotrzebne rzeczy z FILE.

--pomiń-od-re regexp

Pomiń niepotrzebne rzeczy z plików pasujących do wyrażenia regularnego.

--tylko z FILE

Bierz rzeczy tylko z FILE.

--tylko-od-re regexp

Bierz tylko rzeczy z plików pasujących do wyrażenia regularnego.

GCC_OPTIONS

GCC_OPTIONS są przekazywane do gcc -E

POMÓC OPCJE
--help
Wyświetl streszczenie pomocy dla sprawdzam.

PRZYKŁADY

Wszystkie pliki źródłowe są wstępnie przetwarzane za pomocą gcc, więc canonify potrzebuje tych samych informacji
jako kod źródłowy - postępuj zgodnie ze składnią z pliku Makefile, aby dołączyć opcje -I do Cpp (lub
gcc), aby można było zlokalizować wszystkie niezbędne nagłówki. sprawdzam przerwie, jeśli będzie to wymagane
nie można znaleźć nagłówków. Źródło musi być kompilowalne; icheck nie może przetwarzać plików, które
nie można skompilować bezpośrednio. Jeśli brakuje nagłówka instrukcji #include lub w inny sposób
wymaga użycia w specjalny sposób, nie można go bezpośrednio przetworzyć za pomocą icheck.
Zamiast tego napisz plik pośredniczący C, który odpowiednio konfiguruje, a następnie #includes the
header.

sprawdzam --kanonizować -o ~/icheck/stara wersja -I/usr/include/foo-2.0 /usr/src/bar/src/foobar.h

Przygotuj podsumowanie tekstowe pliku foobar.h i wszystkich zawartych w nim plików. Podsumowanie jest
wypisane do ~/icheck/stara wersja. Powtórz dla /usr/src/bar1/src/foobar.h - ten sam plik
w nowszym katalogu źródłowym, wyprowadzenie do nowego pliku, np ~/icheck/nowawersja.

sprawdzam --porównywać -o ~/icheck/results.txt ~/icheck/stara wersja ~/icheck/nowawersja

Zapisuje raport z porównania dwóch plików podsumowania. Raport wskazuje wszystkie
zmiany w ABI i/lub API wykryte podczas porównania.

sprawdzam --kanonizować -o debian/icheck.canonical -Idebian/foo-dev/usr/include debian/foo-
dev/usr/include/foobar.h

sprawdzam --porównywać debian/icheck.manifest debian/icheck.canonical

Te dwa stwierdzenia, zawarte w a debian/zasady plik, spowoduje, że kompilacja pakietu będzie
nie powiedzie się, jeśli interfejs API lub ABI zmienił się w nieoczekiwany sposób, gdzie icheck.manifest jest kopią
oczekiwany interfejs, zawarty w pakiecie.

Zauważ, że argumenty --compare same w sobie są prawidłowymi plikami C, które są wstępnie przetworzone,
więc icheck.manifest może zawierać logikę preprocesora C. Może to być przydatne, gdy pakiet
eksportuje różne interfejsy w zależności od architektury hosta. W tym przypadku nie możesz
zastąp go nową kopią icheck.canonical, gdy zmieni się interfejs i zajdzie taka potrzeba
zaktualizować manifest. Zamiast ręcznie aktualizować cały manifest, umieść
pisemne opisy interfejsów w jednym pliku (icheck.static-manifest), a następnie użyj:

sprawdzam --kanonizować --linia bazowa debian/icheck.static-manifest -o debian/icheck.dynamic-
manifestować

Na koniec utwórz plik icheck.manifest zawierający:
#include "icheck.static-manifest"
#include "icheck.dynamic-manifest"
Dzięki temu możesz aktualizować niektóre części manifestu ręcznie, a jednocześnie automatycznie
generowanie reszty.

WYDAJNOŚĆ

icheck generuje obszerny opis każdej możliwej zmiany API lub ABI, w oparciu o typ
Informacja. Nie bada rzeczywistego kodu programu, więc jest to możliwe
niektóre wykrywane zmiany typu nie są rzeczywistymi zmianami ABI lub API. Jednak to normalnie
dzieje się to tylko wtedy, gdy kod programu został specjalnie dla niego napisany. W razie wątpliwości załóż, że tak
zmianie.

Na koniec icheck wyświetla podsumowanie zmian. Zwróć uwagę, że wskazówki tutaj są
zależne od kolejności argumentów --compare: starszy interfejs musi być pierwszy,
albo kierunki będą odwrotne. Znaczenie różnych terminów jest takie
następuje:

ABI ABI jest kompatybilne, jeśli rzeczy zostały skompilowane z jedną wersją
interfejs będzie działał, gdy zostanie uruchomiony przy użyciu innej wersji.

API Interfejs API jest kompatybilny, jeśli rzeczy zostały skompilowane z jedną wersją
interfejs można zestawić z drugim.

kompatybilny w przód
Interfejs jest kompatybilny w przód, jeśli rzeczy są kompilowane ze starym
wersja będzie działać z nową. Jest to ważna cecha dla imię
zmiany.

wstecznie kompatybilny
Interfejs jest kompatybilny wstecz, jeśli rzeczy są kompilowane z nowym
wersja będzie działać ze starą. Jest to ważna cecha dla shlibs
wersja zmiany. Jeśli nie budujesz pakietów Debiana, prawdopodobnie tego nie robisz
obchodzić się ze zmianami, które nie są wstecznie kompatybilne.

Korzystaj z icheck online, korzystając z usług onworks.net