Vlákno názorů k článku
GCC 5 kompiluje rychle, pořád ale zaostává za Clangem
od OMG - Potká se Pentium a 486 a 486 se...
-
OMG (neregistrovaný)
Potká se Pentium a 486 a 486 se ptá, kolik je 3 + 1. Pentium odpoví 5, 486 po chvilce přemýšlení povídá “to je ale špatně”, načež Pentium opáčí “to je jedno, hlavně, že je to rychle”.
Pokud se jedna o rozsahle projekty, existuje distribuovana kompilace. Pokud se jedna o uzivatelske aplikace, pak rychlost kompilatoru je irelevantni a pokud na ni poukazuji developeri jako na nutnost testu syntaxe, pak budto pouzivaji hloupy editor, nebo pracuji na spatne pozici.
-
koudy (neregistrovaný)
Děkuju! Naprostý souhlas :)
Už jsem se lek, že nad kódem přemýšlím nějak špatně, když mi vymyslet a napsat trvá o poznání déle než trvá kompilace.I pokud dělám na větším projektu, většinou provádím částečný build a jednou za čas je dobrá výmluva "kompiluju" http://xkcd.com/303/
-
Karel (neregistrovaný)
A vidíte, fakt, že vám to vymyslet a napsat trvá tak dlouho, by měl vašeho nadřízeného postavit do pozoru. Buď jste velmi pomalý a drobná úloha vám trvá věčnost, nebo naopak sekáte několik úloh najednou a pak doufáte, že v tom není chyba. Častější je ten druhý případ. To jsou lidé, kterým to po kompilaci padá a oni neví kde začít. S argumentem "no, ještě v říjnu to fungovalo" a smutným konstatováním, že netuší která z těch 23 úprav to rozbila, protože to netestoval po každé úpravě ale až teď po dvou týdnech.
-
koudy (neregistrovaný)
COTO?
To by mě zajímalo jak můžete po 3 větách vědět nad jakými problémy se zamýšlím a jak pracuji? :)
To o nadřízeném nebudu komentovat vůbec..."Trvá tak dlouho" jsem měl v poměru ke kompilaci a ta trvá pár sekund. ( a to určitě ještě přeháním, neskočím si ani pro kafe, při full buildu to na to kafe je jen tak tak )
Jsem programátor, ne čaroděj, nedoufám že něco funguje, ověřuju si to.@Petr M - noční build nemáme, pro způsob jakým vyvíjíme je to nepoužitelné. ( ostrá verze se vydává jednou za x, vždy na vyžádání od zákazníka )
kde x je velmi proměnlivé -
koudy (neregistrovaný)
:) líbí se mi, Váš přístup k problému!
Nevyvíjím pro běžného Frantu uživatele, proto nejde používat běžné postupy.
Nový SW si nasazuje zákazník na své produkční stroje, po jeho otestování.V mém případě nevidím přínos v buildu po každé změně. (je nutné mít aplikace ve stejné verzi jako má zákazník, kvůli testům/stížnostem/opravám/hledání chyb/...)
Samozřejmě se mohu plést a rád si poslechnu cizí názor/zkušenosti.
-
Ondra Satai NekolaZlatý podporovatelTy buildy po kazde zmene se nemuseji nutne nikde pouzivat (mimo nejakych automatickym testum), obvykle se archivuje poslednich par a pak se to odmazava. Dulezite jsou spis protoze kdyz nekdo pushne chybu (at uz rozbijejici v zakladu kompilaci, rozumneji atutomaticke testy), tak mu za chvili prijde mail s upozornenim. Detekuje se, ze stav v repu je nejaky podezrely.
-
koudy (neregistrovaný)
Není nad to otočit se na kolegu a říct "ty vo*e co jsi to dal do toho gitu?" ( vyvíjíme v 5 lidech, takže má člověk přehled, kdo s kým a za kolik - teda kdo na čem pracuje )
Většinou se snažíme do gitu dávat funkční celky a je domluva, že se úpravy "pushují" (sorry češtino) až když mi to chodí v testu a dělá to co má.
Kupodivu to zatím celkem dobře funguje.Chápu, že když se vyvíjí v 20+ lidech, je to o něčem jiném, u nás by ten přínos pravděpodobně nebyl až tak markantní a nevím zda bych to protlačil jako projekt, ale díky za rozumnou argumentaci, musím Vám dát za pravdu, že by se mi něco takového taky líbilo.
-
Petr M (neregistrovaný)
Ok, Franta a Lojza si stáhnou aktuální kód a každý nezávisle implementuje do jinýho modulu nějakou funkcionalitu. Oba použijí nějakou globální proměnnou, třeba status, a exportují z modulu přes external. Každá je jinýho typu, jeden použije enum, druhý char. Oba si to odzkouší, jede jim to a práci komitnou do repozitáře a jede se dál.
V pátek dojde šéf, že je potřeba do pondělka poslat release. Do konce šichty 5h, testování na 4h, domluvený, že vyzvedneš manželku s dětma a jedete na zaplacený víkend v zahraničí. Kliknete na Build a najednou 170 chyb i když oba pánové měli svůj lokální build v pořádku. Refaktor->Rename není možno použít, jmenuje se to přece stejně...
Oproti tomu použít oddělenou větev v GITu se zdrojákama pro release + skript pro vyčištění adresáře, stažení posledních zdrojáků z vývojové větve, build a kontrolu přítomnosti ELF hozený do cronu prakticky nic nestojí a zjistí se to do druhýho pracovního dne bez stresu...
NB má smysl už od dvou lidí, kteří editují zdrojáky.
-
koudy (neregistrovaný)
[OFFTOPIC]
Pro začátek: globálním proměnným je dobré se vyhýbat, pokud to jde, ale je mi jasné, že to uvádíte pouze jako příklad.Pokud počítáte s tím, že proměnou/funkci/... bude používat i někdo jiný je dobré mít domluven nějaký standard. Třeba že status bude vždy enum.
Což je celkem logický požadavek, už jen proto, že to je většinou samo-popisující.
Např.: "STAT_WE_ARE_FU*KED" asi nebude znamenat, že je vše v pořádku.
[OFFTOPIC]Tak jak je tu nastaven postup vývoje, dojde k tomu že si Franta stáhne upravené zdrojáky Lojzou, nebo opačně, k souběhu nedochází - vývojový team je tak malý, že víme co kdo dělá a jsme schopni se domluvit. Většinou ještě před tím, než se vůbec začne vyvíjet.
Kdybych testoval a zkoušel překládat 5h před odevzdáním, tak bych tu dlouho nebyl. :)
K tomu aby přišel šéf a řekl že musíme poslat build NIKDY nedojde!
Takhle to tu prostě nefunguje a ani fungovat nemůže.Náš postup vývoje je očividně naprosto odlišný od Vašeho.
Souhlasím s tím, že NB se hodí při vývoji, když na projektu dělá více lidí, nebo dělají každý v jiném časovém pásmu a podobně. ( pro open source je to asi nutnost )
Dokonce bych řekl že to má velký přínos, když vyvíjíte něco co může kdokoli testovat ( pro takový GIMP by bylo asi nepředstavitelné nemít NB )Čas vložený do odladění všech automatických testů, reportování a cron jobu (ok, tohle je pár řádek :) ) se mi prostě nevrátí.
-
Ondra Satai NekolaZlatý podporovatel
Pokud mas strach z nakladu na zavedeni, tak asi nemusis. Rozbehat jenkinse a v nem nastavit projekt je trivialni.
Ja vidim vyhodu hlavne v tom, ze kontroluje masina a ne lidi.
-
Ondra Satai NekolaZlatý podporovatel
Kdyz na to prijde, nemusis bezet na AIXu, muzes ho bezet, kde chces a nechat ho odpalovat buildy na AIXu pres ssh. Trebas...
-
Petr M (neregistrovaný)
- Pokud se jedna o rozsahle projekty, existuje distribuovana kompilace.
To jistě, můžu si třeba matematickou knihovnu nebo grafiku hodit do knihovny, definovat API a buildovat konkrétní knihovnu + aplikaci beze změn ostatních částí. Make to podporuje a nenní s tím problém. Nemá to ale smysl třeba pro 20 zdrojáků.
- Pokud se jedna o uzivatelske aplikace, pak rychlost kompilatoru je irelevantni a pokud na ni poukazuji developeri jako na nutnost testu syntaxe, pak budto pouzivaji hloupy editor, nebo pracuji na spatne pozici.
Ale ono platí "Cokoliv se samo děje, dobře se děje". Ušetřím si tím nějaký čas a eliminuju lidský chyby, takže ušetřím náklady.
Když píšu nějakou složitější funkcioanlitu, natvrdo hodím funkce a do nich kostry z (ne)existujících funkcí, protože odpovídají úrovni abstrakce. Chci todo list? Build, v reportu chyb seznam toho, co mám implementovat a ještě to v projektu není... něco dopíšu, zase build, ono se to samo aktualizovalo...
Nebo jiná forma automatickýho debilníčku:
#if COSI
...
#elif COSI_DALSIHO
...
#else
#error na cosi jsi zapomnel
#endif
Můžu vidět v IDE zašedlý všechno mimo #error. Ale jenom v případě, že je to zrovna na obrazovce. Po buildu to vidím, ať je to kdekoliv.Pak jsou i další důvody - statická aserce odhalí, že je v tabulce jiný počet prvků, než v enumu pro indexování, Statická analýza podle MISRA je taky z principu kompilace kódu, ...
A je rozhodně lepší kód, který se hlídá sám při kompilaci, než se spolehnout na syntax highlight nebo featury konkrétního IDE. Projekt / modul z něho se může udržovat třeba dalších pět, deset let a migrovat třeba na jinou platformu, takže opovrhovat kompilátorem a jeho schopností hledat chyby bych osobně považoval za nebezpečnější, než 20x denně mačkat na BUILD.
Dobrý pogramátor se chybám aktivně brání a cokoliv mu s tím pomůže, je vítáno. V rozumných mezích (čas, peníze) samozřejmě.
