From: xf0r3m Date: Sun, 28 Apr 2024 16:03:33 +0000 (+0200) Subject: Kontynuowanie tworzenia rozdziału 14. Podrozdział 14.3. X-Git-Url: https://gitweb.morketsmerke.org/?a=commitdiff_plain;h=5b97b33c3184e1f5eebe3aedf1c03d6394ad37ae;p=mmdev.git Kontynuowanie tworzenia rozdziału 14. Podrozdział 14.3. --- diff --git a/articles/terminallog/Linux.Podstawy.html b/articles/terminallog/Linux.Podstawy.html index dfc9632..a2ecbde 100644 --- a/articles/terminallog/Linux.Podstawy.html +++ b/articles/terminallog/Linux.Podstawy.html @@ -11883,7 +11883,278 @@ xf0r3m@laptop-5cfe659:~$ cc -c -I/opt/pt/include netstats.c

14.2.1. Przykładowy plik Makefile

- + Na podstawie dwóch plików z poprzedniego podrozdziału utworzyłem + przykładowy plik Makefile. Plik ten tworzy znany nam + rownież plik myprog, który nie robi nic więcej poza + wyświetleniem napisu Hello, World!. +

+
+xf0r3m@laptop-7bf2993:~/prog/C$ cat Makefile 
+
+OBJS=aux.o main.o
+all: myprog
+myprog: $(OBJS)
+	      $(CC) -o myprog $(OBJS)
+
+

+ W pierwszej linii znajduje się definicja makra, która w tym + przypadku wskazuje na dwie nazwy plików obiektowych + (OBJS=aux.o main.o). W następnej + linii znajduje się bowiem reguła + (all:) reguły jak już wcześniej + wspomniano określają sposób w jaki ma zostać zbudowany cel. W tym + przypadku reguła all: wskazuje + mogłoby się wydawać, że na nasz plik końcowy. Jest to poczęści + prawda, ale zwróćmy uwagę na to, że poza + myprog nie znajduje się nic innego. + W jaki sposób narzędzie make ma wiedzieć jak zbudować ten + ten program. Odpowiedź kryje się w linii niżej, bowiem + myprog jest celem, + a co za tym idzie zależnością dla + all:. W przypadku celu + myprog: widzimy już jakieś konkrety: + pierwszym jest odwołanie się do makra, jest ono rozwiązywane do + nazw zapisanych na początku pliku Makefile, w pliku nie + znajduje się żadne inne elementy systemu Make tak więc + ten cel jest o tych plików uzależniony. Warto dodać, że + Make zakłada, że plki źródłowe znajdują się w tym samym + katalogu co pliki Makefile. Uruchomienie polecenia + make w tym katalogu prezentuje się następująco. +

+
+xf0r3m@laptop-7bf2993:~/prog/C$ make
+cc    -c -o aux.o aux.c
+cc    -c -o main.o main.c
+cc -o myprog aux.o main.o
+
+

+ Poza tym co sami zapisaliśmy w pliku Makefile to nie + wszystkie czynności jakie są wykonywane przez system Make. + W Makefile użyliśmy plików obiektowych, zatem skąd narzędzie + ma wiedzieć o tym, że ma wykorzystać pliki kodu źródłowego + (.c), aby utworzyć pliki obiektowe (.o). Za tego + typu czynności odpowiadają reguły wbudowane. Przez + co osoby zajmujące się utworzeniem plików Makefile mogą + od razu operować na właściwych plikach. +

+

+ Ostatnia linia pliku Makefile jest odpowiedzialna za + zbudowanie właściwego pliku wykonywalnego naszego programu. + Po wcześniejszym przygotowaniu plików obiektowych z plików + źródłowych odwołanie się do makra + $(OBJS) staje się zwykłym + podstawieniem argumentów do polecenia. Ta linia jest zwykłym + poleceniem utworzonym na podstawie makr pliku Makefile. + Każde polecenie w pliku Makefile musi zostać + wprowadzone w nowej linii i poprzedzone + znakiem tabulacji równym czterem znakom spacji. + Makro $(CC) jest zmienną, która + przechowywuje nazwę programu kompilatora C, w wiekszości przypadku + jej wartość będzie ustawiona na cc. +

+

+ Jednym z najczęstszych błędów, jakie możemy doświadczyć na początku + tworzenia plików Makefile jest: +

+
+xf0r3m@laptop-7bf2993:~/prog/C$ make
+Makefile:5: *** brakujący separator. Stop.
+
+

+ Wynika to najczęściej ze złego ustawienia szerokości tabulacji w + naszym edytorze. Ja korzystam z 2 spacji na 1 tab, ze względu na + wytyczne Makefile musiałem zmienić swoje ustawienia. +

+

14.2.2. Aktualizacjia zależności

+

+ Program make został zaprojektowany w taki sposób aby do realizacji + określonego celu była wymagana jak najmniejsza ilość kroków. Tak + więc nie uświadczymy ponownego budowania programu w momencie + ponownego wydania polecenia make. Aczkolwiek jedną z zasad + systemu Make jest to, że cele zawsze powinny być budowane + wraz ze swoimi zależnościami. Taki komunikat otrzymamy gdy + wydamy polecenie make jeszcze raz. +

+
+xf0r3m@laptop-7bf2993:~/prog/C$ make
+make: Nie ma nic do zrobienia w 'all'.
+
+

+ Natomiast jeśli chociażby zmienimy datę, któregoś z plików kodu + źródłowego za pomocą prostego polecenia touch. Wówczas plik + obiektowy będzie starszy niż plik źródłowy i Make dokona + budowy naszego programu ponownie. +

+
+xf0r3m@laptop-7bf2993:~/prog/C$ touch aux.c
+xf0r3m@laptop-7bf2993:~/prog/C$ make
+cc    -c -o aux.o aux.c
+cc -o myprog aux.o main.o
+
+

+ Z tą róźnicą, że zaktualizowany zostanie wyłącznie ten plik, który + został zmieniony oraz ponownie zostanie zbudowany końcowy plik + wykonywalny. +

+

14.2.3. Argumenty i opcje wiersza poleceń programu make

+

+ Uzupełniając wywołanie programu make o różne opcje oraz + argumenty możemy zmusić go do wykonani kilku przydatnych czynności. + Najprostrzym przykładem może być zmiana wartości makra CC, + wskazując inny niż domyślny kompilator. +

+
+$ make CC=clang
+
+

+ Tak utworzone makra mogą być przydatne w trakcie testów. Szczególnie + takie jak CFLAGS oraz LDFLAGS. Innym przypadkiem + może być użycie programu make dla najprostrzych programów + wówczas podajemy nazwe pliku bez rozszerzenia jako argument, + a program zbuduje nam końcowy plik wynikowy o podanej nazwe. Zwróćmy + uwagę, że nie ma potrzeby przygotowania pliku Makefile. +

+
+$ make foo
+cc  foo.o   -o foo
+
+

+ Tego typu uruchmianie narzędzia make bedzie sprawdzać się + w przypadku programów zapisanych w jednym pliku lub programów, w + których jezykiem nie jest C. Jest to drobre rozwiązanie gdy dopiero + rozpoczynamy pracę z danym językiem i nie wiem jeszcze jak działa + kompilator czy inne narzędzia z nim związane. Jeśli nawet zbudowanie + celu się niepowiedzie to i tak otrzymamy informację zwrotną co jest + nie tak. +

+

+ Po za zmianami makr, możemy wykorzystać kilka przydatnych opcji + takich jak: +

+ +

14.2.4. Standardowe makra i zmienne

+

+ System make posiada wiele predefiniowanych zmiennych oraz + makr. Sama różnica między makrami i zmiennymi jest trudna do + określenia. Dlatego też przyjęło się, że makra są niezmienne przez + cały okres trwania jakiegoś procesu. W tym przypadku nazwiemy tak + wszystko co nie zmieni się od momemntu rozpoczęcia procesu + budowania celów zawartych w pliku Makefile. +

+

+ Najczęsciej wykorzystywane makra to między innymi: +

+ +

+ Poza makrami w narzędziu make możemy korzystać ze zmiennych. + Zmienne mogą zmienić się podczas budowania zdefiowanych celów w + Makefile. Najczęściej jednak będziemy się spotykać ze + zmiennymi zdefiniowanymi automatycznie w obrębie reguł celów. Oto + trzy z nich: +

+ +

14.2.5. Typowe cele kompilacji

+

+ W plikach makefile odpowiedzialnych za pokierowanie systemu + make faktycznych programów użytkowych możemy spotkać wiele + innych celów realizujących zadania niekoniecznie związane z + kompilacją. Są one predefiniowane przez make i oto kilka z + nich: +

+ +

14.2.6. Organizowanie pliku Makefile

+

+ Istnieje wiele róznych stylów tworzenia plików Makefile, + mimo tego stosowanych jest kilka ogólnych zasad. W pierwszej + częsci pliku, najcześciej spotykane są (jako definiecje makr) + opcje bibliotek oraz plików nagłówkowych po grupowanych wg. + określonych pakietów. +

+
+MYPACKAGE_INCLUDES=-I/usr/local/include/mypackage
+MYPACKAGE_LIB=-L/usr/local/lib/mypackage -lmypackage
+PNG_INCLUDES=-I/usr/local/include
+PNG_LIB=-L/usr/local/lib -lpng
+
+

+ Następnie zapisywane są makra z opcjami kompilatora oraz opcje + konsolidatora każde z opcji zapisywane jest w osobnym makrze. +

+
+CFLAGS=$(CFLAGS) $(X_INCLUDES) $(PNG_INCLUDES)
+LDFLAGS=$(LDFLAGS) $(X_LIB) $(PNG_LIB)
+
+

+ Po tych opcjach zapisywana jest hierarchia makr opisujących pliki + obiektowe. Hierarchia ze względu na zależności. +

+
+UTIL_OBJS=util.o
+BORING_OBJS=$(UTIL_OBJS) boring.o
+TRITE_OBJS=$(UTIL_OBJS) trite.o
+PROGS=boring trite
+
+

+ W pozostałej częsci plików występują już cele, które składają główne + pliki wykonywalne. Jeśli trzeb przygować regułę dla pliku obiektowego + należy ją umieścić zaraz nad regułą programu pliku wykonywalnego. + Jeśli z tego pliku obiektowego korzysta więcej plików wykonywalnych + niż ten jednen to trzeba je przenieść nad nie wszystkie.