Makefile pro větší projekty

Minule jsme si ukázali, jak napsat Makefile pro velmi jednoduchý projekt. Zkusme se nyní zamyslet, jak by se Makefile změnil, kdyby se jednalo o středně velký projekt z několika desítek zdrojových souborů. Základní cíle včetně linkování výsledného projektu by se příliš nezkomplikovaly, ale neúnosně složitým by se stal výčet pomocných pravidel pro jednotlivé objektové soubory, zejména ruční zápis závislostí na hlavičkových souborech. Jeden *.c soubor může inkludovat třeba 5 hlavičkových souborů, přičemž řada z nich může inkludovat jiné hlavičkové soubory, takže rekurzivní průchod #include příkazů je nad síly programátora. Částečným řešením je definice všech hlavičkových souborů projektu do jedné proměnné v Makefile a přidání této závislosti do jednotlivých pravidel.

hlavicky=soubor1.h soubor2.h souborN.h

# ...

souborX.o: souborX.c ${hlavicky}
	gcc souborX.c -c

Toto řešení má určitou nevýhodu, že přidává do Makefile závislost všech *.c souborů na všech *.h, takže změna libovolného hlavičkového souboru při vývoji způsobí, že se celý projekt musí překládat od začátku, ale v praxi to příliš nevadí, neboť v běžných projektech je i skutečná závislost *.c na *.h velká. Další nevýhodou je, že v Makefile musí být i nyní pro každý objektový *.o soubor explicitně uvedené pravidlo, ačkoli se všechny překládají v podstatě stejným způsobem.

Práci si můžeme ušetřit, pokud použijeme v Makefile implicitní pravidla nebo pokud budeme vytvářet Makefile z nějaké šablony sadou standardních nástrojů (autoconf, automake). V našem seriálu si ukážeme pouze první způsob.

Implicitní pravidla

Pokud není splněna v Makefile závislost (například neexistuje soubor main.o) a není pro ni uvedené žádné pravidlo, pokusí se ji make splnit pomocí implicitního pravidla. Ta jsou definována pro běžné typy souborů zpracovávané pomocí make, nás bude zajímat pravidlo pro vytvoření souborXY.o ze souborXY.c. Toto implicitní pravidlo vypadá následovně:

souborXY.o: souborXY.c
	${CC} ${CFLAGS} ${CPPFLAGS} -c -o souborXY.o souborXY.c 

Stačí tedy nastavit proměnné CC a CFLAGS, proměnnou CPPFLAGS můžeme nechat prázdnou.

# překladač C
CC=gcc
# nepovinný parametr, míra optimalizace
CFLAGS=-O2

Poslední, co je třeba udělat, je určení závislostí na hlavičkových souborech. Pokud se spokojíme se závislostí všech *.c na všech *.h, může to vypadat třeba takhle:

OBJ=soubor1.o soubor2.o souborN.o
HEAD=soubor1.h soubor2.h souborN.h

# hromadné nastavení závislostí, žádná akce
${OBJ}: ${HEAD}

Makefile pro příklad z minulého a předminulého dílu by mohl vypadat asi takhle:

#
# Makefile pro pokusný příklad 16. - 18. dílu seriálu o C/C++ na linuxsoft.cz
#

# Jméno přeloženého programu
program=priklad

# Seznam objektových souborů použijeme hned na třech místech.
OBJ=funkce.o main.o
SRC=funkce.c main.c
HEAD=funkce.h

# Míra optimalizace překladače gcc
OPT=-O2

# Překladač C
CC=gcc

# Nepovinné parametry překladače
CFLAGS=${OPT}

# Cílům build, install, uninstall, clean a distrib neodpovídá přímo žádný soubor

.PHONY: build
.PHONY: install
.PHONY: uninstall
.PHONY: clean
.PHONY: distrib

# První cíl je implicitní, není třeba volat 'make build', stačí 'make'.
# Cíl build nemá žádnou akci, jen závislost.

build: ${program}

# install závisí na přeložení projektu, volat ho může jen root
install: build
	cp ${program} /usr/bin

# uninstall má jenom akci a žádnou závislost, volat ho může jen root
uninstall:
	rm -f /usr/bin/${program}

# clean smaže soubory po překladu
clean:
	rm -f *.o ${program}

# distrib vytvoří balíček s kompletním zdrojovým kódem
# akce na dva řádky se napíše pomocí zpětného lomítka

distrib:
	tar -c ${SRC} ${HEAD} Makefile > c18.tar; \
	gzip c18.tar

${program}: ${OBJ}
	${CC} ${OBJ} -o ${program} ${OPT}

# Závislost všech objektových souborů na všech hlavičkových
${OBJ}: ${HEAD}

# A to je vše, pravidla pro main.o a funkce.o není třeba uvádět

Celý příklad si můžete stáhnout zabalený jako c18.tar.gz. Všimněte si, že přidání nového zdrojového souboru do projektu spočívá v modifikaci proměnných OBJ a SRC nebo HEAD, jde tedy jen o malou změnu Makefile na jednom místě. U našeho projektu ze tří zdrojových souborů to není důležité, ale již v případě středně velkých projektů je tato vlastnost téměř nutností.

Je třeba říci, že organizace překladu projektů C na Unixu není ustálená, používá se více způsobů překladu od sestavovacích skriptů přes ručně psaný Makefile až po generování Makefile z nějaké jednodušší šablony. Za standardní byť poněkud kontroverzní řešení se považuje postupné generování (velmi složitého a pro člověka téměř nečitelného) Makefile z jednoduchého Makefile.am a configure.in pomocí automaku a autoconfu a jimi vygenerovaného shellového skriptu configure, ale popis těchto komplikovaných nástrojů by značně přesáhl cíle tohoto seriálu a částečně i autorovy znalosti.

Rychlokurs gdb

Minule jsem zmínil parametr -g překladače gcc, který zajistí přidání ladících informací do kódu. V našem Makefile stačí nastavit OPT=-g a celý projekt znovu přeložit.

make clean
make

Standardním nástrojem pro ladění programů napsaných v C na Linuxu je řádkový debugger gdb. Používá se buď přímo, nebo prostřednictvím nějaké nadstavby typu ddd, xxgdb nebo KDbg. Krokování programů v prostředích jako je KDevelop a emacs je ve skutečnosti také implementováno pomocí gdb. My si ukážeme krokování laděného programu přímo v gdb.

#include <stdio.h>
#include <stdlib.h>

int nadruhou(int n) {
  int i, suma;

  for (i = 0; i <= n; i++) {
    suma += n;
  }
  return suma;
}

int main(int argc, char **argv) {
  int n;
  
  if (argc < 2) {
    puts("syntaxe: nadruhou číslo");
    return 1;
  }
  n = atoi(argv[1]);
  n = nadruhou(n);
  printf("%i\n", n);
  return 0;
}

Uvedený program má zkonvertovat svůj první parametr na celé číslo a na standardní výstup vypsat jeho druhou mocninu. Aby to nebylo tak jednoduché, máme zadavatelem zakázáno v programu násobit, takže druhou mocninu musíme vypočítat přičítáním v cyklu. Do programu se nám ovšem vloudila chyba.

$ gcc nadruhou.c -g -o nadruhou
$ ./nadruhou 1
2
$

Jedna na druhou jistě není 2, takže musíme program ladit.

$ gdb nadruhou
(gdb)

Zadáme parametry programu, nastavíme breakpoint na začátek funkce main a spustíme program.

(gdb) set args 1
(gdb) break main
Breakpoint 1 at 0x80483e2: file nadruhou.c, line 17.
(gdb) run 

Program se spustí, ale hned na začátku main se díky breakpointu zastaví. K základním příkazům gdb patří

• break funkce
  Vlož breakpoint na začátek funkce.
• break soubor:řádek
  Vlož breakpoint na příslušné místo.
• delete
  Smaž breakpoint určený parametrem nebo všechny breakpointy.
• continue
  Pokračuj k dalšímu breakpointu nebo do konce programu.
• next
  Krok bez zanoření do volané funkce.
• step
  Krok se zanořením do volané funkce.
• list
  Výpis kódu programu v okolí aktuální pozice.
• print výraz
  Výpis hodnoty výrazu.
• help
  Nápověda, může mít jako parametr příkaz nebo skupinu příkazů.

Podobně jako například v bashi můžeme pomocí šipek nahoru a dolů listovat minulými příkazy, funguje hledání pomocí Ctrl+r, enter znamená opakování předchozího příkazu atd.

Po dvou next můžeme zadat například print argv[1] a print n, čímž zjistíme, že k chybě dojde až ve funkci nadruhou. Příkazem step se dostaneme dovnitř funkce a zjištění, že for cyklus běží o jednu iteraci déle, než by měl, je už záležitostí několika příkazů next a print.

Ukázali jsme si jen základy gdb, zájemce o hlubší znalosti odkazuji na manuálové stránky a návody a články na webu. Určitě stojí za to vyzkoušet některou z grafických nadstaveb gdb. Z vlastní praxe vím, že gdb se hodí především pro ladění menších projektů a často se nedá rozumně použít při vývoji programů využívajících vlákna. V těchto případech je obvykle vhodné umožnit oddělení kritické části programu (například složitý algoritmus) odladit ji samostatně. Pokud ani toto řešení není možné, bývá zpravidla nejlepší se gdb vzdát a najít chybu pomocí ladících výpisů.

Pokračování příště

V dalším dílu se vrátíme k základní syntaxi jazyka C, probereme příkaz switch a bitové operátory.