V článku o make Kosťa temno zaprorokoval:
I když se bude ze začátku zdát, že IDE (Code::Blocks, Eclipse, ....) Vás před touto znalosti ochrání, tak vězte neochrání - Bude hůř
Náš starý známy nič netušiaci programátor sa zhrozil - ale potom sa zháčil - veď prečo by ten make mal byť takým hrôzu budiacim driemajúcim drakom? Opýtal sa teda, virtuálne, samotného Kosťu (a keďže sa jedná o virtuálneho Kosťu, odpovedal nám plynulou slovenčinou ):


Nič Netušiaci Programátor [NNP]: Tak čo to ten make vlastne robí?
Virtuálny Kosťa [VK]: Určuje, ako sa budú prekladať jednotlivé súbory projektu, a ako sa zlinkujú dohromady.
[NNP]: Len to? Veď to sa mi vždy urobí automaticky keď stlačím F9! (podľa potreby si čitateľ nahradí obľúbenou klávesou spúšťajúcou preklad - pozn. wek)
[VK]: No a čo myslíš, čo to tvoje IDE vtedy spraví?
[NNP]: Neviem - zachraští diskom, a na určenom mieste sa objaví výsledný .hex... (podľa potreby si čitateľ nahradí obľúbenou príponou výsledného súboru po preklade - pozn. wek). Autori IDE sa určite namakali kým ten zázrak vytvorili...
[VK]: Prdlajs. IDE obvykle neurobí vôbec nič, iba spustí make. Najviac čo môže urobiť je, že predtým na základe Tebou naklikaného "projektu" (t.j. zoznamu zdrojových súborov) vygeneruje podľa pravidiel, čo si vymyslel tvorca toho IDE, nejaký makefile.
[NNP]: Čo je to makefile?
[VK]: Súbor predpisujúci programu make čo má robiť. Akýsi skript (zoznam pokynov) - a make je akýsi interpreter toho skriptu.
[NNP]: No to je na mňa veľa... Ale počkaj, veď môj projekt má len jeden zdrojový súbor (blikač.c), tak načo mi je make?
[VK]: No lebo sa do toho tvojho blikača prilinkujú knižnice... čo myslíš, odkiaľ sa zoberie kód, ak napíšeš msdelay()?
[NNP]: No, dal som tam predsa #include ...
[VK]: Fajn, ale to je len hlavičkový súbor, tam sú len deklarácie funkcií - skutočné telo je v knižniciach a po preklade ich treba prilinkovať.
[NNP]: Čo je to vlastne linkovať?
[VK]: Ach akí su tí dnešní mladí sprostí... Preklad v C tradične pozostáva z 1.predprocesingu, to sa napr. vložia #include-nuté súbory, vyhodia komentáre a všetko čo je podmienene prekladané (#ifdef) a podmienka neplatí, nahradia sa makrá svojimi definíciami (#define)... 2. samotného prekladu z C do asembleru (ó áno, áno, kto by to bol povedal... ), 3. preklad z asembleru do relokovateľného bináru - tzv. objektu (.o, .obj) - tam ešte nie je jasné, kam presne do pamäte sa to všetko naskladá. To všetko sa obvykle udeje spustením jediného programu - ten má buď všetky tri zložky v sebe, alebo vie aké iné programy má spustiť s akými parametrami. Objekty sa potom musia spolu zlepiť, tomu sa hovorí linkovanie.
[NNP]: A čo sú to knižnice?
[VK]: To sú zbierky hotových rutín.
[NNP]: A tie sú kde?
[VK]: Pri inštalácii ich inštalátor narval niekam do adresárového stromu, kde sú aj jednotlivé programy (a iné súbory) prekladača.
[NNP]: A odkiaľ to prekladač vie, kde sú?
[VK]: No presne tak isto ako odkiaľ prekladač vie, kde sú štandardné headery ktoré sa #include-ujú, keď sa uzavrú do <>.
[NNP]: A to je...?
[VK]: No, sú nejaké dohodnuté spôsoby - nejaká konkrétna relatívna pozícia voči samotnému programu prekladača (napr. prekladač je v /prekladac/bin a voči tomuto adresáru sú knižnice v ../lib, t.j. v /prekladac/lib a headery v ../include t.j. /prekladac/include), obsah nejakej dohodnutej premennej systému (to čo sa nastavuje cez systémový príkaz set alebo nejaký podobný), alebo je v nejakom konfiguračnom súbore, alebo sa priamo zadá ako parameter pri spustení prekladača - obvykle je ich viacero a prekladač skúsi všetky v nejakom stanovenom poradí. Nájdi si dokumentáciu od svojho prekladača a prečítaj si ju.
[NNP]: A odkiaľ prekladač vie, ktorá časť knižnice patrí ku ktorému #include-nutému headeru?
[VK]:No, to je tá blbosť u C, že to nevie (skalní zástancovia C to formulujú tak, že je to "jedna z perfektných vlastností C"). Medzi headermi a kódom, ktorého rozhranie majú popisovať, nie je absolútne žiadna väzba, okrem "disciplíny" ("iný header než ku knižniciam dodávaný nepoužiješ"). Jednoducho prekladač prejde všetkými knižnicami a povyberá z nich funkcie použité v programe, to je všetko.
[NNP]: No dobre, trocha sme odbočili... A nedalo by sa to všetko - môj zdroják aj knižnice - pekne zlepiť do jediného zdrojového súboru (trebárs použitím includov, tak ako s headermi) a prekladať ten?
[VK]: No tak to je dobrá blbosť.
[NNP]: Prečo?
[VK]: No lebo 1. ku knižniciam sa obvykle zdrojáky nedodávajú, sú to binárne objeky (to že sa u gcc dávajú, je v skutočnosti anomália); 2. knižnice sú rozsiahle a je výhodné ich mať už vopred preložené aby sa nestrácal čas pri preklade; 3. veľké zdrojové súbory sa prekladajú pomaly, a obvykle rastie čas prekladu s veľkosťou zdrojových súborov rýchlejšie než lineárne, takže sa oplatí ho rozbiť na viacero malých (a to platí už aj o tvojom programe, máš ho písať modulárne aj z týchto dôvodov)
[NNP]: Tak dobre, chápem. Ale vravíš že ten make je vlastne len interpreter skriptu. Nedá sa teda použiť normálny skript - v DOS/Win .bat, v *nux nejaky shell skript? Jednoducho spustím najprv prekladač pre všetky C zdrojáky, a potom linker s tým, že mu vymenujem všetky .obj]... to by malo stačiť, nie?
[VK]: Áno, stačí to - ale zbytočne budeš vždy prekladať všetky súbory, aj tie čo sa nezmenili.
[NNP]: No a? Veď to je len chrrrrrrrps na disku a je to, nie?
[VK]: Mno, ak máš multimegagigahertzový stroj, a prekladáš blikač.c, tak áno. Ale ak už máš nejaký rozsiahlejší projekt na ktorom pracuje viacero ľudí a zdrojáky majú dohromady stovky tisíc alebo až milióny riadkov.... taký preklad "všetkého", ak by trval čo i len 20-30 sekúnd, zakaždým keď zmeníš jeden riadok v jednom bezvýznamnom module ktorý nič nemení na 95% zvyšného kódu, tak to ťa veľmi rýchlo parádne otrávi... sa ti to zdá málo? Skús pomaly napočítať do dvadsať a nič pri tom nerobiť...
[NNP]: No a toto make akože vyrieši?
[VK]: Áno. Toto je najdôležitejší dôvod sa s make vôbec zapodievať.
[NNP]: A ako to prosím Ťa robí?
[VK]: Nuž, make nie je obyčajný skript. Je to vlastne zoznam, čo od čoho závisí: typicky napríklad, blikač.hex závisí od blikač.obj, a blikač.obj závisí od blikač.c . A ešte sa dá predpísať, že ak teda B závisí od A, čo treba robiť, aby z A vzniklo B (v skutočnosti to "čo treba robiť" môže byť úplne akýkoľvek príkaz či sada príkazov - tie sa len jednoducho odovzdajú operačnému systému - a vôbec nemusia vyrobiť B z A. Ale obvykle to tak je.) Make ide od konca, a zistí, na čom všetkom je výsledok (blikač.hex) závislý, a ak v tom reťazci (či skôr strome) závislostí je čokoľvek, čo sa od posledného prekladu zmenilo, no tak od neho sa začne a vykoná sa všetko čo treba aby sa dospelo k výsledku.
[NNP]: A odkiaľ make vie, čo sa zmenilo? Necháva si niekde schované súbory, cez ktoré prechádzal, a porovnáva, či sa v nich niečo nezmenilo?
[VK]: Ale kdeže. Toto je tool pochádzajúci z Unixu, a tam je všetko primitívne jednoduché. Jednoducho sa porovnáva čas vytvorenia resp. poslednej zmeny súboru. Ak súbor B závisí od súboru A, a A je "novší" ako "B", tak sa súvisiaca činnosť vykoná, inak nie.
[NNP]: No ale to predsa môže ľahko zlyhať - napríklad keď sa mení letný čas a OS alebo samotný make sa neriadi nejakým univerzálnym časom... alebo keď sa časť súborov prenesie z počítača na ktorom z nejakých dôvodov je inak nastavený čas?
[VK]: ... no, áno. Ale s unixovskými nástrojmi to je tak. Sú jednoduché, silné, a obvykle v sebe skrývajú nejakú komplikovanú záludnosť. Teraz už o tom vieš, tak si dáš pozor.
[NNP]: No ja neviem, je toho priveľa. A ešte som pozeral aký je ten makefile komplikovaný...
[VK]: ... a to je nič oproti faktu, že sa tam využíva tabulátor ako syntaktický prvok - ďalšia záludnosť na ktorú si treba dávať pozor, najmä ak makefile edituješ v editore ktorý automaticky nahrádza tabulátor medzerami (čo u normálnych súborov je dobrá vec), alebo ak ho automaticky vytváraš nejakým nástrojom, ktorý by tie tabulátory mohol nahradiť...
[NNP]: A nie je nejaká rozumná alternatíva?
[VK]: Ale je. Sú alternatívne make - napr. cmake - a niekteré IDE majú zabudovaný svoj make systém, nevolajú externý program. A je hromada programov ktoré makefile na základe nejakých vstupných údajov automaticky vygenerujú - napr. automake; a napokon aj väčšina spomínaných IDE. Ale spomeň si na moje proroctvo...
[NNP]: Prečo, prečo nemôžem ostať u môjho obľúbeného tlačítka F9 v IDE?
[VK]: Lebo Ti to vydrží na blikač.c a ešte pár jednoduchých úloh. Akonáhle príde niečo zložitejšie - potreba prilinkovať externý súbor, naviac generovaný pomocou nejakého iného programu, alebo ak chceš použiť iné než defaultné knižnice, príp. nejaké dodatočné knižnice s nejakými záludnosťami, alebo niečo podobné - je treba iný makefile než ten generovaný, ktorý vychádza z nejakých viac-menej fixných predpokladov ktoré si stanovil tvorca IDE.
[NNP]: Ale ja som s tým spokojný, mne to stačí...
[VK]: O to lepšie. Aspoň nás, starých harcovníkov, vy, uchá nedoučené, nebudete pripravovať o prácu...

(Rozhovor medzi virtuálnym Kosťom a Nič Netušiacim Programátorom po vzkriesení na záver odpadnuvšieho NNP zapísal wek)