Večeras smo na “sastanku” ULK-a nešto malo diskutirali, pa evo linka za raju:
http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html
Možete se neslagati sa prezentiranim mišljenjem, a ako hoćete opovrgnuti, napišite protiv-studiju :-p
Jedan mali dodatak.
Autor teksta je donekle u pravu. No, treba naglasiti da prezentirane sheme i nije potrebno implementirati ako ne postoji zavisnost izmedju modula u make-u.
S duge strane, jedan ogroman make je nemoguce odrzavati (pogledajte Aegis ili Cook), i predstavljaju nesto tipa “generisi i zaboravi”. Ovim se dobija nesto kao: brzina vs. odrzavanje. Mnogi maintainer-i ce se odluciti na ovo drugo (narocito ako se radi o jako velikom broju fajlova), ili pak na prelazak u drugi build sistem.
S.
Nije ni mislio reći da sve mora biti baš jedna velika Makefile datoteka. Top level Makefile bi se trebao sastojati od “include” direktiva 
Ideja je ne pokretati rekurzivno Make u svakom poddirektoriju osim u jasno definisanim slučajevima.
Jeste, ali šta ako se tvoj projekat sastoji od podprojekata od kojih je svaki nezavisan?
Npr. kao što se kdebase paket sastoji od Konqueror, Kate, KControl…
Ako je svaki nezavisan, dure, ali nešto ne vjerujem da je Konqueror dovoljno nezavisan od ostatka čitavog KDE base paketa. KDE je ipak framework, a ne component based sistem.
Pa nije ali može biti. Distribucije drže neke od komponenti u zasebnim RPMovima. Ili ako uzmemo da kdebase treba imati jedinstven make, šta je sa kdeextragear (gdje je svaki paket bukvalno za sebe)?