freetype

[Jakub Bogusz]

On Tue, Apr 09, 2002 at 08:52:23PM +0200, Mariusz Mazur wrote:
> On Tuesday 09 April 2002 20:25, Mariusz Mazur wrote:
> > Potrzebna mi osoba która decydowała w jakich katalogach mają siedzieć
> > headersy do freetype i freetype1. Moje pytanie brzmi: czym się ta osoba
> > kierowała rozmieszczając te pliki w obrębie /usr/include?

Chyba nikt się nie kierował, tylko samo się tak umieściło
w standardowych instalacjach tych bibliotek.

> Informacja wstępna:
> freetype1-devel (wersja starsza) trzyma nagłówki w /usr/include/freetype
> freetype-devel (wersja nowsza) trzyma nagłówki w
>                                           /usr/include/freetype2/freetype
> 
> Dobra. Wytłumaczę o co mi chodzi. Otóż podczas moich bojów z mozillą 0.9.9 
> wpadłem na to, że mozilla się ślicznie buduje bez pakietów freetype1-devel, 
> ale z nimi już się wykrzacza. Błędy wskazywały jasno na to, że includowane 
> były pliki z obu wersji freetype'a. Naszukawszy się chwile narzędzia do 
> parsowania plików *.c i robienia drzewka includeów (zna ktoś coś takiego?) 
> wziąłem się na sposób i użyłem do tego celu strace'a. Rzeczywiście okazało 
> się, że są używane nagłówki z obu wersji biblioteki. Pytanie: dlaczego?
> Nie musiałem długo szukać by znaleźć odpowiedź.
[...]
> Dla mnie jest jasne, że autorzy freetype'a nakazali ludziom używania notacji 
> w stylu #include FT_FREETYPE_H zamiast bezpośredniego odwoływania się do tych 
> plików. I tu się rodzi problem. Każdy normalny program podczas kompilacji 
> szuka swoich nagłówków w /usr/include. A co się stanie jeśli includujemy plik 
> <freetype/freetype.h>? Ano includujemy plik /usr/include/freetype/freetype.h 
> należący do freetype1 i tym samym nic się nie kompiluje.
> 
> Teraz wyjścia są dwa: albo zmienimy miejsce w którym znajduje się freetype1 
> (/usr/include/freetype) psując przy okazji dużo rzeczy (i tutaj chciałbym się 
> dowiedzieć, czy ktoś ma jakieś informacje o tym jakie położenie tych plików 
> sugerują sami autorzy), albo w powyższych #defineach pozamieniam 
> <freetype/jakiśplik.h> na <freetype2/freetype/jakiśplik.h>.

To drugie to na pewno nie jest dobry sposób dołączania nagłówków
freetype2 (raczej brzydki workaround).
<freetype/jakiśplik.h> jest OK, ale gcc musi dostać -I/usr/include/freetype2.
-I z linii poleceń mają priorytet przed /usr/include; problemy pojawiają się,
kiedy przed tym -I/usr/include/freetype2 z jakichś powodów pojawi się
-I/usr/include.

Niezależnie od tego - IMO można przenieść nagłówki freetype1
z /usr/include/freetype do /usr/include/freetype1/freetype (tak jest np.
w RH 7.x i rawhide), żeby uniknąć takich problemów.
Dużo się nie zepsuje - z freetype1 już mało co korzysta:

$ grep -l '^BuildReq.*freetype1' *.spec
enlightenment.spec
freeamp.spec
gfontview.spec
imlib2.spec
libast.spec
libuta.spec
magicpoint.spec
siag.spec
ttmkfdir.spec
w3cam.spec
xmbdfed.spec

Poprawki ograniczyłyby się do dodania -I/usr/include/freetype1
- powinno wystarczyć w samych specach, bez konieczności łatania
(jeżeli optflags było dobrze obsługiwane - tak, to "korzyść uboczna"
z używania wszędzie optymalizacji :)).


-- 
Jakub Bogusz    http://prioris.mini.pw.edu.pl/~qboosh/