ARM a Makefile

[Petr Labaj]

Proc lidi nepouzivaji Makefile? Protoze spousta lidi ani nevi, co to je (tim ted zrovna
nemyslim vzorek lidi z hw.cz, i kdyz i tady se obcas vyskytuji nazory, ze je vhodnejsi
pouzit predchystany example, nez se snazit problemtiku nastudovat).
Kdyz se podivate do prakticky libovolneho fora o programovani nejakeho procesoru,
tak kazda druha otazka tam je "pod Eclipse to chodi, ale pod mym XYZ to nejde".
Nikdo z nich nepremysli nad tim, ze preklad je veci kompilatoru, tedy toolchainu,
a ze s tim ma barevna klikaci nadstavba IDE spojitost jen okrajovou.

Konkretne:
- knihovny prekladam predem a delam z nich jednu knihovnu (*.a)
- knihovny jsou ulozene v pevne definovanem adresari, ktery je spolecny pro
  vsechny projekty
- adresar projektu ma shodne jseno s projektem, v nem jsou podadresare:
  - src
  - include
  - ld
  - tmp
- v adresari projektu je jen Makefile, vystup "projekt.elf" a soubor s opisem hlasek
  z prekladu "projekt.txt", vcetne vypisu o delce code a data
- v podadresari tmp jsou *.obj, *,lst ke kazdemu modulu, "projekt.map" a "projekt.dis",
  coz je nejkompletnejsi mozny disassembler vysledneho projektu, vcetne hexdumpu,
  tedy veskera informace pro pripadne hledani
- Makefile ma krome obvykleho "clean" jeste "clean_tmp", ktery maze pracovni soubory,
  ale ponecha "projekt.elf" a "projekt.txt".

Diky predkompilovanym knihovnam je build projektu velmi rychly.
Na urovni systemu je pradnastavena volba -j pro paralelni preklad. Mym cilem
vzdy je, aby jedno kolo preklad+link nikdy netrvalo dele nez 2 sekundy (na Linuxu, kde
mi soucasne toolchainy, natr. pro STM32, chodi vyrazne rychleji nez na Windows).
Pokud by to melo u hodne velkeho projektu trvat dele, je treba se zamyslet a rozlozit to.
Knihovny pouzivam jen naprosto minimalne, vetsinu veci si radeji napisu sam a vim,
co a jak tam je. A muzu to snadno preportovat jinam.
Vyjimkou jsou hodne komplexni periferie jako USB a Ethernet.
S verzovacimi SW jsem se nikdy neszil (coz povazuji za svou chybu). Takze verzovani
pomoci pojmenovanych *.zip.

PL

  ----- Original Message ----- 
  From: František Burian 
  To: hw-list na list.hw.cz 
  Sent: Saturday, January 26, 2013 7:58 PM
  Subject: ARM a Makefile


  Zdravím osazenstvo,

    Mám tu záludné dotazy na sobotní večer. 

    Všechny example které tu proběhly jsou nativní pro Code::Blocks. Chtěl bych se zeptat (čistě z neznalosti) 
  z jakých důvodů nikdo nevytváříte projekt jako Makefile. Myslím že pro možnost kompilace pod různými OS 
  (a že tu jsou i lidé z Linuxových luhů a hájů) by byl Makefile lepší volbou. Zakládat nový projekt na kterém v 
  budoucnosti může pracovat více lidí jako Makefile, nebo jako standardní C::B projekt ?

    Druhý dotaz směřuje k zakládání projektu - když bych chtěl od počátku založit projekt tak, aby jej snadno 
  chápali druzí, aby zkušení v něm dobře "četli", aby šel například zkompilovat i bez Code::Blocks, jakým způsobem 
  bych měl rozčlenit adresářovou strukturu ? Rád bych věděl Vaše názory jak zakládáte své projekty, případně 
  jak členíte strukturu. Řekněme že se jedná o středně rozsáhlý projekt, kde bude komunikace s PC, nějaké UI s 
  "točítkama" pro uživatele, nějaká matematika. Vše v rámci ARM mikrokontroleru (STM32F1 nebo STM32F4). 

    Třetí dotaz směřuje též k založení a "znovupoužití" projektu někým jiným - jedná se o stahování a instalaci 
  periferních knihoven, ve kterých jsou změny oproti originálu. Přikládat a verzovat tuto knihovnu společně s 
  projektem, nebo raději napsat uživateli postup odkud stáhnout a co kde a jak přeplácnout a modifikovat v tom 
  originálu. Já bych byl pro první variantu, ještě nevím zdali to není rozpor s licencí (musím prověřit) ale zdá se 
  mi to přístupnější většímu počtu uživatelů. (na zprovoznění by stačilo mít provozuschopný toolchain a jen 
  stáhnout zdrojový kód z SVN). Uvažujme situaci jeden projekt (tedy NE situaci kdy knihovnu využívá vícero 
  projektů)

  Dík za tipy.

    Franta.
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20130126/79d3113a/attachment.htm>