Vlákno názorů k článku
Vývojáři GCC diskutují o konci dalších neudržovaných CPU architektur
od cc - A přitom testovat 1x za rok mi přijde...
-
Filip JirsákStříbrný podporovatelTam bude hlavní problém sehnat zařízení s příslušným hardwarem. CI je hezká věc, ale musíte mít kde ho spustit.
-
Ale o tom přesně mluvím.
Nemít HW pro CI znamená, že to může kdokoliv kdykoliv rozbít a pořád to někdo bude muset fixovat, když zjistí, že to nefunguje. Naprosto zbytečná zátěž pro vývojáře a celý projekt.
No, a pokud je něco rok rozbité a nikdo o tom neví, tak asi nemá cenu takový port vůbec podporovat, protože to nikdo nepoužívá...
-
Filip JirsákStříbrný podporovatel
No a nebo se to nerozbije a těch pár uživatelů, co to používá, to bude bez problémů používat i nadále. A řešit, že se to rozbilo, budou teprve tehdy, až se to rozbije.
-
To není otázka jestli se to rozbije, to je otázka kdy se to rozbije a kolik bude stát úsilí zjistit proč se to tak stalo a jak to opravit. Někdy je oprava triviální, ale někdy to znamená dělat bisect a ztratit na tom moře času.
Navíc co s takovým bugem, že se rozbila architektura X, když nikdo z vývojářů tu architekturu nepoužívá a nemá to ani CI, jak to takový vývojář vůbec může opravit?
Jak říkám, ztráta času. Ať si to řeší ti co to potřebujou a nezatěžovat tím hlavní team.
13. 8. 2025, 20:51 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Takže protože by to mohlo přestat fungovat v budoucnu, radši to znefunkčníme hned. Proč, když to nikomu nevadí? Hlavní tým to nezatěžuje.
-
Můžeme udělat experiment - každý bug ohledně nepodporované architektury v GCC bude řešit Filip Jirsák. Třeba za 5 let uvidíme, kolik ho to stálo času a kolik jich vyřešil.
Čas není zadarmo - pokud něco nefunguje a nikdo to neumí spravit popř. ověřit, že to funguje, nemá smysl to udržovat. Pro takové lidi co ty architektury třeba používají jsou pořád starší verze GCC.
-
Filip JirsákStříbrný podporovatel
Pokud se v nějaké komponentě řeší bugy, je podporovaná.
Vy se pořád tváříte, jako by ty nepodporované architektury představovaly pro někoho zátěž. Jenže když se v té architektuře objeví nějaká chyba, tak ji nikdo neřeší. Takže to nikoho nezatěžuje. Zatěžovat by někoho mohlo to, pokud se dělá nějaká změna napříč celým GCC a je potřeba sáhnout i do těchto architektur (a je to něco složitějšího než nějaké triviální vyhledej-a-nahraď, které se udělá stejně pro všechny architektury). Pokud něco takového nastane, pak ať se ty nepodporované architektury klidně vyhodí.
Ale proč je pořád chcete vyhazovat preventivně dopředu, když s ponecháním žádná relevantní práce spojená není?
-
Filip JirsákStříbrný podporovatel
Kolik issue na ty architektury tam je? Nenapadá vás, že vývojáři GCC možná vědí lépe než vy, co je doopravdy zatěžuje a co ne?
-
BTW ty diskutované porty, pro pana Jirsáka:
> Here is the list of ports without a maintainer in MAINTAINERS with some
> extra information on when the last time the port was touched for non
> infrastructure changes:
> epiphany - Jeff Law and Jakub Jelinek did a fix each in 2024 before
> that Joern Rennecke did a fix in 2016Doesn't reliably work. Essentially the port will trigger faults during
reload and relatively subtle changes in the IL prior to reload will
cause tests to flip between aborting and compiling.I made an attempt to fix this stuff a while back, but never was able to
get things limping along far enough to get stable test results one day
to the next.> m32c - Last fix done by Bernd Edlinger in Jan 2015
Won't even build libgcc these days.
> rl78 - Last fix done by Jeff Law in October 2018
Builds and tests. A bit flakey, but mostly working. If it's not LRA
enabled, then it should likely go to the deprecation list.Shrnutí: Ty porty nejsou ani funkční, takže o čem tady ta diskuze vůbec je?
-
Filip JirsákStříbrný podporovatel
Jo, akorát že vývojáři GCC diskutují o tom, zda nezavést pravidlo, že je potřeba alespoň jednou ručně pro danou architekturu mít výsledky GCC test suite. Vy jste při šel s tím, že by pro každou architekturu musela být CI. To je něco nesrovnatelného. Proto se ptám vás, proč vy chcete být daleko přísnější než vývojáři GCC.
-
Filip JirsákStříbrný podporovatel
Nemyslím si to já, myslí si to vývojář GCC. A je to lepší například pro to, že je to reálné, na rozdíl od CI pro všechny podporované architektury.
-
Ale ty architektury o kterých se diskutuje nefungujou - to je to - není CI, nefunguje to...
Compiler není projekt, kde by všechno leželo a nikdo tam nic nedělal. Má to aktivní vývoj a CI je jediná možnost jak zajistit kvalitu portů. O tom já diskutuju.
Vy tady pořád plácáte o tom, že když to tam je, tak to ničemu nevadí... jenže to tam je a nefunguje to... je to tam k ničemu.
BTW už to nehodlám dál komentovat - tato diskuze je k ničemu a nebaví mě, mám život...
14. 8. 2025, 21:11 editováno autorem komentáře
-
No tak udelat v dnesnim opensource svete nejaky standardni HIL reseni by nemel byt problem - hlavne pro ty MCU. A provozne je to za par prispevku - coz udelaj nadsenci / uzivatele. To neni jako provozovat 1kW bestii s 2kW diskovym polem :D
Spis vidim problem v nedostatecne dokumentaci az se neco nebude chovat podle ocekavani - na podporovane platforme vam to zkontroluje support team a vyvojari od vyrobce a reknou.. jo, je tam nejaka frikulinska souhra okolnosti a konkretni duvod je xyz, pridaj to do Errata a jede se dal.
U architektur a implementaci ktere nemaji aktivni podporu (at uz jsou EOL nebo vyrobce zanikl), je to jako s udrzovanim rodinneho prislusnika pri zivote v komatu..
