Jonathan Corbet na łamach LWN opisał obecne dyskusje nad wyposażeniem GCC w mechanizm wtyczek. Przy programie o takim stopniu komplikacji, który w dodatku obsługuje wiele niezależnych języków, zyski wydają się oczywiste, jednak istnieją też przeciwskazania.
Wśród najważniejszych argumentów przeciw takiej przebudowie znalazła się łatwość “wstrzykiwania” własnościowych dodatków (kwestia ideowa) oraz problem z utrzymywanie stabilnego API, jak to już widzieliśmy w jądrze Linux (kwestia techniczna).
żadnych reklam, sama wiedza.
Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.
Bez reklam.
Ostatnimi czasy GCC naprawde niezle zaczal radzic. Kod, ktory jest ostatnio pisany (sledze poczytania GCC od mniej wiecej powstania 4.3) jest duzo lepszej jakosci niz kiedys, lecz narazie nie bralbym realnie planow modulowego GCC. Deweloperzy maja duzo wazniejsze rzeczy do napisania, mnostwo rzeczy musi zostac przepisanych (sa czesci kodu, ktorych NIKT nie rozumie, serio!), szczegolnie backend. Nie zapomnijmy tez ze deweloperow GCC, ktorzy sa na stale jest okolo 10ciu (to apropos porownania kwestii technicznych do Linuksa).
Co do kwestii ideowych, o ile moze super by bylo gdyby mogly powstawac programy bazujace na GCC do analizy kodu i wnioslo by to pewno wiele dobrego, to jednak rozposciera sie gorsza wizja przede mna: Biorac pod uwage, ze w tej chwili sa problemy z kompilowaniem programow pod roznymi dystrybucjami (rozne wersje GCC itp), to istnieje dodatkowo mozliwosc, ze niektore dystrybucje (a to one wlasnie oplacaja wiekszosc programistow GCC) zaczna tworzyc jakies rozszerzenia specjalnie pod siebie, i wtedy moze sie okazac, ze problemy z przenosnocia kodu beda jeszcze wieksze, co nie wplynie raczej pozytywnie. FSF takie postepowanie jest na pewno nie na reke 🙂
Konczac polecam komenatarz stevenb'a, na LWN.net. Jest deweloperem GCC od siedmiu lat i ma pojecie facet o czym pisze.
"Kod, ktory jest ostatnio pisany (sledze poczytania GCC od mniej wiecej powstania 4.3) jest duzo lepszej jakosci niz kiedys"
Niestety jak sie pisze od poczatku cos jako broken by design[TM] to sie nie dziwie ze teraz musza nadrawiac.
"The whole design of GCC is perverted so that someone cannot easily extract a front-end or back-end. This is broken by design, as the GPL people do believe this would make it easier for commercial entities to `steal' a front-end or back-end and attach it to a proprietary code-generator (or language)."
zrodlo: http://undeadly.org/cgi?action=article&sid=20…
To niech sie zastanowia moze, czy chca robic WOLNE oprogramowanie dla wszystkich i robic to dobrze czy tez na sile wsztko utrudniac (w tym tez glownie sobie i developerom wolnego oprogramowania), ludzie ktorzy pisza na licencji BSD nie maja takich dziwnych problemow, pisza cos co jest w 100% wolne, i KAZDY moze to wykorzystac, i osoba prywatna, i korporacja, no strings attached[TM].
Zabawne jest, ze ludzie ktorzy tak duzo mowia o otwartosci oprogramowania tak bardzo utrudniaja jego rozpowszechanie, hipokryzja sie klania.
Coz, nie widzialbym raczej az tak zlej woli programistow 🙂 Generalnie praca przy GCC to ciezki kawalek chleba, dlatego osob ktore przy tym cos robia jest niewiele no i duza wiekszosc z ich jest dobrze oplacana. Wczesniej to co wyszlo z pod palcy programistow to byl prawdziwy koszmar, ale teraz naprawde jest duzo lepiej :> i moim zdaniem bedzie lepiej; wydanie GCC 4.4 idzie w dobrym kierunku (zarowno ideologicznym jak i techicznym). Wszystkich problemow nie da sie tez odrazu rozwiazac, nie zapomnijmy jak duza ilosc jezykow i platform GCC obsluguje, a projektowanie rozwiazan "uniwersalnych" jest trudniejsze no i nie zawsze sie konczy dobrze 😛
Śledzisz rozwój od 4.3, wcześniej było gorzej (przed forkiem egcs było w ogóle tragicznie). Ale na szczęście obecnie są dobrze wydzielone moduły (front, middle i back-end).
Rozwój Gcc idzie w dobrym kierunku, ale na razie jest jeszcze w 20 wieku. Długie cykle wydań, nieumiejetne korzystanie z z VCS (patrz ostatnia dyskusja nt. wpisów w ChangeLogs), Subversion, problemy z zarządzaniem (mimo, że core-team, przyznaję: mały, pracuje nad Gcc za pieniądze). Na dodatek jest jeszcze wątpliwy przymus przepisania praw autorskich na FSF.
Rozumiem, że porównywanie rozwoju Gcc do Linuksa (jądro) jest nie w porządku bo mają znacznie mniej deweloperów. Ale popatrz jak rozwija się Wine i zestaw to z modelem rozwoju Gcc.
Sledze dokladnie rozwoj (czyli analizuje kod :)) od 4.3, ale generalnie wiem jak wyglada historia GCC. I faktycznie, w ogole przed EGCS to byla tragiedia. Co do porownania z Wine, to z tego co wiem to w Wine w ogole wszystko przechodzi przez jedna osobe, ktora jest tam mistrzem-guru. Mam kolege (nota bene dewelopera Wine), ktory zawsze chwiali Wine za rozwoj. Trzeba przyznac, Wine ma czeste wydania itd. Z drugiej strony jednak no coz, Wine dziala..w miare, i ma taki komfort, ze jak cos nie bedzie dzialac, to najwyzej sie to wylaczy i pojdzie odpalic u kolegi na windzie. GCC nie ma takich przywilejow, bo ja cos sie zrobi nie tak, to sie moze okazac ze wszystkie dystrybucje leza ;] A co FSF to szczerze mowiac nie mam zdania i sie nie wypowiadam :]
rozwiazaniem problemow z gcc jest… llvm 😉
duzo czytelniejszy, obecnie generujacy optymalniejszy kod, modularny, moze wykorzystywac gcc w niektorych aspektach, przygotowany m.in. pod katem mozliwosci analizy kodu
LLVM nie generuje optymalniejszego kodu. Jeszcze nie.
rzeczywiscie – zle dobralem slowa…
bytecode llvm uruchamiany na jit vm llvm potrafi sie wykonywac szybciej, niz podobny kod binarny wygenerowany przez gcc…
oczywiscie zawsze mozna powiedziec ze wszystko zalezy od odpowiedniego spreparowania testu…
android apple bezpieczeństwo biznes google hardware internet iphone kaspersky media microsoft mobile open-source press-release programowanie software UNIX windows Wydania Wydarzenia
Dodaj komentarz