Atlantis <m...@w...pl> napisał(a):
> Kompilator zwrócił serię błędów, wskazując na plik nagłówkowy
> zaimportowanej biblioteki. Wszystkie one dotyczyły nieznanego typu
> zmiennej: "unknown type name 'uint16_t'" (tudzież uint8_t),
> występującego w deklaracjach nazw funkcji, umieszczonych w owym pliku
> nagłówkowym. Same definicje funkcji w pliku .c już o nic nie krzyczały.
> Doszedłem do tego, że winny jest brak dyrektywy #include <avr/io.h> na
> początku feralnego pliku nagłówkowego, który ze względu na nazwę jest
> sprawdzany przez kompilator jako pierwszy.

Jak to ze względu na nazwę? Kompilator leci po kolei po linijkach kodu.

> Mam teraz następujące wyjścia:
> 1. Umieścić #include już na początku pliku nagłówkowego, ale chyba nie
> jest to zbyt eleganckim wyjściem.

Dlaczego nie? Skoro plik używa tych typów, to powinien zawierać includy
definiujące te typy.

Tutaj jest w ogóle trochę specyficzna sytuacja. Mówimy bowiem o podstawowych
typach dla AVR (i dla innych uC też), które są wykorzystywane praktycznie w
każdym projekcie. Z tego względu praktycznie każdy plik .c będzie miał
includa dla io.h i będzie importować te typy. Często będzie to pierwsza
linijka w pliku .c. Z tego względu jeśli potem jest include biblioteki, to
te typy są już znane i plik .h biblioteki nie musi ich kompilować. Dlatego
autor biblioteki nie zaincludował io.h w pliku .h swojej biblioteki. Po
prostu założył, że Ty to zrobisz w pliku .c i zrobisz to _przed_
includowaniem jego biblioteki.

Przyznam się, że nie wiem jakie wyjście jest tu uznawane za eleganckie. Moim
jednak zdaniem biblioteka powinna zawierać wszystko co potrzeba i jak
zaincludujemy jej plik .h to nie powinniśmy być zmuszaniu do includowania
innych nagłówków definiujących typy wykorzystywane wewnętrznie przez tą
bibliotekę. No chyba, że uznajemy io.h za wyjątek.

> Na różnych przykłądach widzę, że te
> dyrektywy umieszcza się raczej w plikach *.c.

Kompilator analizując plik .c nie może widzieć żadnych nieznanych wyrażeń,
musi mieć wszystko wcześniej zadeklarowane (niekoniecznie zdefiniowane, ale
zadeklarowane tak). Stosujemy więc pliki nagłówkowe żeby udostępniać
deklaracje typów i funkcji, definicje funkcji siedzą w plikach .c.
Tutaj jest sytuacja taka, że plik .h odwołuje się do typów, których nie ma
standardowo w języku C, dlatego w pliku .h może być odwołanie do innego
pliku .h. Nie jest to nic dziwnego w bardziej złożonych projektach.

> 2. Zmienić nazwy plików tak, aby kompilowały się później.

Po pierwsze kolejność kompilacji nie ma nic do rzeczy. Po drugie o
kolejności decyduje plik Makefile albo inny skrypt budujący (zależnie od
środowiska).

> A może istnieje jakiś sposób na poinformowanie kompilatora, żeby
> dołączył określony plik już na samym początku? Albo żeby zmienił
> kolejność kompilacji poszczególnych plików?

Poczytaj sobie jak działa kompilator. Kompiluje oddzielnie poszczególne
pliki .c, zgodnie z tym, co ma wpisane w Makefile. I przestań mylić
kompilację z dołączaniem plików .h. Kolejność kompilacji nie ma nic
wspólnego z kolejnością dołączania. Pytasz o sposób informowania kompilatora
o dołączanie na samym początku. Dołączanie jest przecież realizowane w
kodzie źródłowym poprzez dyrektywy #include. W jakiej kolejności je
napiszesz, w takiej wskazywane przez nie pliki będą dołączane. Poza tym mam
wrażenie, że myślisz, że plik nagłówkowy się dołącza raz na cały projekt.
Nie. On się dołącza w tym miejscu, w którym jest #include. I koniec końców
dołączany jest to jakiegoś jednego, konkretnego pliku .c. Pliki .c są
kompilowane oddzielnie i nie wiedzą o sobie. Dlatego includy często się
powtarzają. Dopiero jak wszystkie pliki .c są skompilowane, to wkracza
linker tworząc wynikowy plik wykonywalny i zapisując w nim skoki pod
określone adresy. Dlatego w jednym pliku .c możesz odwoływać się do funkcji
zdefiniowanej w drugim. Ale ten pierwszy musi znać deklarację.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 2 days, 18 hours, 52 minutes and 5 seconds