OT hadanka s make na predlzeny vikend

[Jan Waclawek]

Tak som sa sam so sebou dohodol na tomto rieseni:

- skutocny makefile premenujem na makefile.real

- v makefile.real, zoznam suborov, ktore vstupuju do linkovania, dam do
premennej ELF_PREREQUISITES 

- v makefile.real vytvorim novy target version.timestamp, ktory ma ako
prerequisites tiez ELF_PREREQUISITES, a ako recept to, ze pomocou touch
vytvori/zmeni cas suboru version.timestamp a tiez zmeni cas suboru
version.h na aktualny

- za recept pre elf pridam recept pre inkrement cisla verzie vo version.h a
za nim pomocou touch zmenim cas version.h na nejaky velmi stary

- vytvorim novy makefile pod menom makefile, v ktorom pre "vedlajsie"
targety (typicky clean) je jednoducho len "volany" makefile.real s tym
targetom

- pre target all je "volany" makefile.real najprv s targetom
version.timestamp a potom s targetom all


Toto sposobi, ze:

- pri prvom volani "make -f makefile.real version.timestamp" sa vdaka
zavislosti version.timestamp (ktory ma v podstate rovnaky cas ako posledny
vytvoreny .elf, urcite starsi ako kazde nasledne rucne editovanie
zdrojovych suborov) na ELF_PREREQUISITES skompiluju vsetky subory ktore
boli zmenene; pricom sa subory, ktore zavisia na version.h, nekompiluju,
ak neboli explicitne zmenene, kedze version.h ma cas velmi stary. Toto by
malo pochytit vsetky zavislosti vratane vnorenych do dalsich makefile.

- ak sa pritom zisti, ze nic nebolo treba kompilovat, version.timestamp sa
nezmeni, a version.h zostane velmi stary

- ak sa nieco prekladalo, version.timestamp aj version.h sa zmenia na
aktualny

- pri druhom volani "make -f makefile.real x.elf" (all je ekvivalentny
x.elf), ak sa v prvom kroku nic nezmenilo, tak sa tiez nic nespravi; ak sa
zmenilo, tak sa skompiluju vsetky subory ktore zavisia na version.h (kedze
ten je novsi ako posledne skompilovane objekty) a urobi sa linkovanie; a
potom sa version.h umelo zmeni na stary


Vyhoda je, ze:
- "neplytva" sa zbytocne verziami (co ma za pozitivny nasledok aj to, ze
nezmenene zdrojaky napr. z archivu sa vzdy skompiluju na ten isty binar aj
po viacnasobnej "rekompilacii", toto moze byt vyznamne napr. pri urcitych
certifikacnych postupoch)

- nelinkuje sa zbytocne, pri velkom projekte to moze usetrit vyznamny cas


Nedostatky tohto postupu su:

- dvakrat sa robi kontrola zavislosti na celom strome, ale to obvykle
netrva dlho, typicky daleko menej ako linkovanie

- ak sa explicitne zmeni niektory zo suborov zavislych na version.h,
kompiluje sa dvakrat (to obvykle nevadi, tie subory typicky obsahuju len
definiciu premennej inicializovanej tou verziou, alebo nieco podobne
jednoduche)


wek


-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.zip
Type: application/x-zip-compressed
Size: 1160 bytes
Desc: not available
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20150513/fb8740e7/attachment.bin>