> C'est bien simple, d'après ce que je lisais, il n'y a tout simplement pas
> de main d'oeuvre dans OpenBSD (parce que pas de temps libre, trop
> de trucs plus urgents à faire) à consacrer à un compilateur quelconque.
Pas beaucoup - pas assez - mais un petit peu quand même (de la main d'oeuvre). Par ex. :
- Un ou deux employés de Coverity (boite qui maintient un fork de gcc dédié à l'analyse statique de code) sont des développeurs d'OpenBSD (au moins Ted Unangst)
- Marc Espie, qui maintient depuis longtemps les semi forks de gcc (2.95 et 3.3.5 + patchs propolice) dans le système de base et dans les ports (4.0, 4.1, 4.2), et qui a les droits en écriture/commit dans le vrai depot svn de gcc
- Un certain nombre de développeurs ont cultivé des compétences liées, en ré-écrivant récemment le lint d'OpenBSD pour en faire un outil puissant et moderne (à la place de l'ancien lint, peu utilisable car floodeur de false positives)
- Maintenance, depuis longtemps,d'une paire de versions de gcc très adaptées à leurs besoins
- Et un paquet de spécialistes sur les « architectures minoritaires » (hppa, arm, mvme88k, ppc, sparc, ...).
Ce n'est certainement pas assez pour développer seuls un nouveau compilateur C complet, mais tout de même bien utile pour collaborer, avec d'autres, sur un compilateur déjà existant et bien architecturé. Au final ça ne fera sûrement pas un compilateur aussi complet (nombres de langages supportés) ou optimisé que gcc, mais fera probablement un bel outil complémentaire de gcc, pratique pour ceux qui ont les mêmes besoins qu'eux. Pas de raisons de s'en plaindre : ça n'enlève rien à personne, et ça profitera à certains.
Pour faire un peu d'informatique prédictive/fumeuse/astrologique ;), mon paris, c'est que ça donnera d'ici quelque temps un petit compilateur :
- C only (car ils n'ont pas besoins de C++ ou autre dans le système de base (sauf pour grof, mais il sera sûrement remplacé...))
- très rapide (car c'est un problème immédiat de gcc dont ils souffrent depuis longtemps, et qui leur coûte du temps)
- ayant une relative compatibilité avec les extensions gcc (ils en utilisent, et en auront besoin pour les ports)
- intégrant des fonctionnalités utiles pour la sécurité (puisqu'ils maintiennent déjà de nombreuses extensions de ce type dans leur fork "in house" de gcc)
- supportant un nombre décent d'architectures (puisque c'est capital pour eux et pour NetBSD)
- produisant du code peu optimisé (parce que ça demande beaucoup de travail et n'est pas une priorité immédiate pour eux, en tout cas moins importante que la rapidité de compilation)
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par herodiade . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 5.
> de main d'oeuvre dans OpenBSD (parce que pas de temps libre, trop
> de trucs plus urgents à faire) à consacrer à un compilateur quelconque.
Pas beaucoup - pas assez - mais un petit peu quand même (de la main d'oeuvre). Par ex. :
- Un ou deux employés de Coverity (boite qui maintient un fork de gcc dédié à l'analyse statique de code) sont des développeurs d'OpenBSD (au moins Ted Unangst)
- Marc Espie, qui maintient depuis longtemps les semi forks de gcc (2.95 et 3.3.5 + patchs propolice) dans le système de base et dans les ports (4.0, 4.1, 4.2), et qui a les droits en écriture/commit dans le vrai depot svn de gcc
- Un certain nombre de développeurs ont cultivé des compétences liées, en ré-écrivant récemment le lint d'OpenBSD pour en faire un outil puissant et moderne (à la place de l'ancien lint, peu utilisable car floodeur de false positives)
- Maintenance, depuis longtemps,d'une paire de versions de gcc très adaptées à leurs besoins
- Et un paquet de spécialistes sur les « architectures minoritaires » (hppa, arm, mvme88k, ppc, sparc, ...).
Ce n'est certainement pas assez pour développer seuls un nouveau compilateur C complet, mais tout de même bien utile pour collaborer, avec d'autres, sur un compilateur déjà existant et bien architecturé. Au final ça ne fera sûrement pas un compilateur aussi complet (nombres de langages supportés) ou optimisé que gcc, mais fera probablement un bel outil complémentaire de gcc, pratique pour ceux qui ont les mêmes besoins qu'eux. Pas de raisons de s'en plaindre : ça n'enlève rien à personne, et ça profitera à certains.
Pour faire un peu d'informatique prédictive/fumeuse/astrologique ;), mon paris, c'est que ça donnera d'ici quelque temps un petit compilateur :
- C only (car ils n'ont pas besoins de C++ ou autre dans le système de base (sauf pour grof, mais il sera sûrement remplacé...))
- très rapide (car c'est un problème immédiat de gcc dont ils souffrent depuis longtemps, et qui leur coûte du temps)
- ayant une relative compatibilité avec les extensions gcc (ils en utilisent, et en auront besoin pour les ports)
- intégrant des fonctionnalités utiles pour la sécurité (puisqu'ils maintiennent déjà de nombreuses extensions de ce type dans leur fork "in house" de gcc)
- supportant un nombre décent d'architectures (puisque c'est capital pour eux et pour NetBSD)
- produisant du code peu optimisé (parce que ça demande beaucoup de travail et n'est pas une priorité immédiate pour eux, en tout cas moins importante que la rapidité de compilation)