PKG_CHECK_MODULES() i niekompatybilne wersje bibliotek.

0

Dzień dobry,

Z tego co wyczytałem, biblioteki dzielone (.so) w Linuxie posiadają 3-członowe (czasem tylko 2) numery w nazwie, np:

/usr/lib64/libcairo.so.2.11400.6

przy czym pierwsza liczba (2-jka w przykładzie) jest zwiększana przy wprowadzeniu niekompatybilnych zmian w bibliotece.
Zatem funkcja foo() w wersji 2.11400.6 może zadziałać inaczej w wersji 3.0.0 biblioteki, lub może zostać w ogóle z niej usunięta.
Jeśli zatem, pisząc program, używam funkcji, która dobrze działa od wersji 2.11400.6 biblioteki, to program skompiluje
się u końcowego użytkownika, jeśli będzie miał zainstalowaną bibliotekę w wersji:

2.11400.n, gdzie n >= 6
lub
2.m.n, gdzie m >= 11400, n dowolne.

a może nie skompilować się, lub skompiluje się, ale będzie niepoprawnie działał, jeśli u użytkownika jest zainstalowana
tylko wesja:

m.n.o, gdzie m > 2, n i o dowolne, bo zwiększenie pierwszej liczby oznacza niekompatybilną zmianę.

Stąd moje pytanie:

Jak napisać makro

PKG_CHECK_MODULES([CAIRO], [cairo >= 2.11400.6])

aby ./configure pozwolił mi połączyć program z tą samą lub nowszą kompatybilną wersją biblioteki,
ale nie pozwolił połączyć programu z nowszą ale niekompatybilną wersją (większa pierwsza liczba)?

Z testów jakie przeprowadziłem PKG_CHECK_MODULES() nie przejmuje się tym, że zwiększenie pierwszej
liczby wprowadza niekompatybilność i pozwala łączyć z wersją 3.m.n.

--
Irko

PS.

cairo robi tutaj jako przykład, chodzi o generalną zasadę dot. wykrywania bezpiecznych wersji bibliotek.

0

Ten schemat nazewnictwa, o którym piszesz, to semantic versioning. I choć byłoby pięknie, żeby wszyscy się do niego stosowali, to tak jednak nie jest i sporo ludzi numeruje inaczej. Przykłady — Python (gdzie przeskoki na drugim miejscu są mniej poważne) albo TeX i pochodne (dopisują kolejną cyfrę do numeru wersji).

1 użytkowników online, w tym zalogowanych: 0, gości: 1