OpenBSD supporte officiellement des archis très vieilles et lentes comme Vax. Et ils ont pour habitude de compiler tout le cvs en boucle (pour intercepter les problèmes de portabilité - tout les devs n'ont pas un Vax ou un mac68k à la maison - et en même temps pour stresser la VM sur ces diverses archs normalement peu utilisées (donc moins testées)).
Ils n'ont pas les moyens financiers de Linux (nombreuses sociétés et particuliers impliqués dans le dev/testing kernel et la libc + distros pour réparer en aval), pour s'offrir de gros clusters de Vax, Zaurus, hppa et de mac68k (et payer la note d'éléctricité !) à chaque fois qu'un header d'X.org ou de la libc change.
On peut donc aisément comprendre leur besoins de compilations rapides.
D'autre part, et au moins pour le moment, il ne s'agit pas de *remplacer* gcc par pcc (ni même de produire les binaires finaux de certaines archs avec pcc). Je crois que pour le moment l'intéret immédiat est simplement de disposer d'un compilo très rapide, pour accélérer le développement et la remontée de bugs, mais gcc reste là. D'après les explications que j'ai pu lire, c'est la motivation déterminante (et non une guerre de religion sur la licence).
(ps: accessoirement, recompiler tout le système avec un nouveau compilateur permet aussi de trouver de nouveaux bugs dans le système : Anders Magnusson dit avoir trouvé plein de bugs en compilant le userland NetBSD avec pcc).
[^] # Besoin de vitesse de compilation (au moins pendant les cycles de dev)
Posté par herodiade . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 10.
Ils n'ont pas les moyens financiers de Linux (nombreuses sociétés et particuliers impliqués dans le dev/testing kernel et la libc + distros pour réparer en aval), pour s'offrir de gros clusters de Vax, Zaurus, hppa et de mac68k (et payer la note d'éléctricité !) à chaque fois qu'un header d'X.org ou de la libc change.
On peut donc aisément comprendre leur besoins de compilations rapides.
D'autre part, et au moins pour le moment, il ne s'agit pas de *remplacer* gcc par pcc (ni même de produire les binaires finaux de certaines archs avec pcc). Je crois que pour le moment l'intéret immédiat est simplement de disposer d'un compilo très rapide, pour accélérer le développement et la remontée de bugs, mais gcc reste là. D'après les explications que j'ai pu lire, c'est la motivation déterminante (et non une guerre de religion sur la licence).
(ps: accessoirement, recompiler tout le système avec un nouveau compilateur permet aussi de trouver de nouveaux bugs dans le système : Anders Magnusson dit avoir trouvé plein de bugs en compilant le userland NetBSD avec pcc).