[MontelLUG] Fork e compilatori [Era] manifesto Linux Day

[Davide Rondini]

> > Argh, un altro compilatore nooo... Perché non chiamarlo Yet Another C
> > Compiler? Capisco l'esigenza di migliorare le prestazioni, di inserire
> > feature nuove, ma non era meglio fare un branch sperimentale e testare
> > nuove cose lì?
> 
> L'approccio è abbastanza diverso e più "moderno". Clang è solamente un
> frontend di LLVM, uno strumento che permette di fare cose che nessun
> fork di GCC avrebbe mai permesso:
> http://www.phoronix.com/scan.php?page=news_item&px=ODY4Nw
> http://www.phoronix.com/scan.php?page=news_item&px=ODcyOQ
> http://www.phoronix.com/scan.php?page=article&item=gallium3d_llvmpipe&num=1
> http://www.phoronix.com/scan.php?page=article&item=intel_glsl2_llvmpipe&num
> =1

Bah, questo è opinabile: anche gcc stesso è stato praticamente riscritto da 
zero nel passaggio dalle versioni 3.x alle 4.x, tra l'altro proprio separando 
la struttura logica in tre parti (back-end, middle-end e front-end), proprio 
per renderlo più flessibile. Non mi sono addentrato in tutti quei link, ma 
dalla wikipedia leggo che che LLVM già usava gcc come front end, quindi perché 
scriverne un altro?

http://it.wikipedia.org/wiki/LLVM

Quello che obietto non è di paralizzare lo sviluppo per non osare riscrivere 
certi pezzi di codice con approcci innovativi, dico solo che certe cose si 
potrebbero concentrare in un unico team di sviluppo, in seno a un singolo 
progetto, in modo da non sprecare risorse.

> 
> > Un compilatore non è un player MP3, che si cambia dalla sera alla
> > mattina, ci sono problemi di adattamento del codice, compatibilità con
> > le applicazioni, con le librerie C... GCC funziona bene e pressoché
> > ovunque (mentre questo se non capisco male, non è compatibile con
> > Windows): perché farne un altro, disperdendo risore (i programmatori di
> > compilatori mica si trovano al supermercato)?
> 
> Perché come ho scritto l'approccio è più moderno e "astratto". Alle
> volte per adattarsi a cambiamenti radicali dell'hardware (la
> computazione che si sposta sempre più dalle CPU alle GPU programmabili)
> è meglio riprogettare e riscrivere il software da zero, piuttosto che
> creare dei Frankenstein che non fanno bene né una cosa né un'altra.

Non credo che GCC sia così "legnoso" da non poter prevedere di poter compilare 
codice che giri anche sulle GPU. La struttura è pensata apposta per poterci 
innestare front-end e back-end per linguaggi e piattaforme hardware più 
disparati possibile.

> 
> > Capisco l'esigenza di Apple, ma adesso ci si troverà con Linux
> > che va con un compilatore e BSD con un altro.
> 
> Se sono già riusciti a compilare una Debian fino a Xorg e farla girare
> già adesso può darsi che si troveranno distro Clang-compatibili facilmente.
> 
> L'eccesso di varianti crea casini, ma è altrettanto vero il contrario:
> il monopolio, la fossilizzazione e l'accettazione dello "status quo"
> possono essere altrettanto pericolosi per il futuro di un sistema
> dinamico come quello informatico.
> 

Appunto: non c'erano già abbastanza build di Debian?

Non ho mai parlato di mantenere il sacro GCC immutabile e intoccabile, dico 
solo che non mi pareva il caso di disperdere risorse di sviluppo in progetti 
che in fondo fanno la stessa cosa.

Ciao
CD