Pour l'instant, le truc qui coince c'est la compatibilité binaire avec BeOS qui nous force à utiliser un gcc 2.95.3 (avec pas mal de patchs...). C'est la principale raison qui motive cette tentative de faire une version 1 rapidement (c'est dans la roadmap du projet, la version 1 doit etre compatible avec BeOS). Une fois qu'on a sorti cette version 1, on pourra enfin démarrer le travail de mise à jour de l'API (il y a eu des améliorations, mais on commence à atteindre les limites de ce qui peut etre fait sans casser la compatibilité).
Comme à ce moment là il y aura une version stable et supportée de Haiku, de nouvelles applications pourront etre développées, et (on espère) remplaceront les quelques applications BeOS pour lesquelles il n'y a pas encore d'alternative crédible. Ensuite il n'y aura plus de problème pour casser la compatibilité et on pourra avancer.
Cela ne s'applique que pour la version x86 (et pas les versions x86_64 et ARM) de Haiku, c'est la seule ou la compatibilité est assurée. On a aussi un compilateur gcc4 pour compiler les applications modernes, bien sur. Donc, actuellement on peut remplacer gcc4 par clang (et ne pas avoir de compatiblité gcc2). Il reste un peu de travail pour:
- Améliorer le code en supprimant les warnings levés par clang (mais ce n'est pas toujours possible si le code doit continuer à compiler avec gcc2)
- Supprimer ou réduire le plus possible l'utilisation des extensions de gcc (idem)
- Tester le système ainsi compilé et vérifier qu'il n'y a pas de régressions (a priori non, ça a l'air de tourner comme il faut), et que le code généré est au moins aussi performant (ça n'est pas nécessairement le cas, la plupart des benchmarks de clang le teste avec un jeu d'instruction moderne (SSE, SSE2, SSSE, ...) mais Haiku est toujours compilé pour une cible 586 (MMX, et rien d'autre) (pour la version x86 uniquement).
Donc, ça fonctionne déjà, mais c'est peu testé, donc il semble raisonable de sortir une version R1 dont on est surs qu'elle est stable et de faire ce changement ensuite (pour la version R1.1 ou R2, par exemple).
[^] # Re: Clang ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
Pour l'instant, le truc qui coince c'est la compatibilité binaire avec BeOS qui nous force à utiliser un gcc 2.95.3 (avec pas mal de patchs...). C'est la principale raison qui motive cette tentative de faire une version 1 rapidement (c'est dans la roadmap du projet, la version 1 doit etre compatible avec BeOS). Une fois qu'on a sorti cette version 1, on pourra enfin démarrer le travail de mise à jour de l'API (il y a eu des améliorations, mais on commence à atteindre les limites de ce qui peut etre fait sans casser la compatibilité).
Comme à ce moment là il y aura une version stable et supportée de Haiku, de nouvelles applications pourront etre développées, et (on espère) remplaceront les quelques applications BeOS pour lesquelles il n'y a pas encore d'alternative crédible. Ensuite il n'y aura plus de problème pour casser la compatibilité et on pourra avancer.
Cela ne s'applique que pour la version x86 (et pas les versions x86_64 et ARM) de Haiku, c'est la seule ou la compatibilité est assurée. On a aussi un compilateur gcc4 pour compiler les applications modernes, bien sur. Donc, actuellement on peut remplacer gcc4 par clang (et ne pas avoir de compatiblité gcc2). Il reste un peu de travail pour:
- Améliorer le code en supprimant les warnings levés par clang (mais ce n'est pas toujours possible si le code doit continuer à compiler avec gcc2)
- Supprimer ou réduire le plus possible l'utilisation des extensions de gcc (idem)
- Tester le système ainsi compilé et vérifier qu'il n'y a pas de régressions (a priori non, ça a l'air de tourner comme il faut), et que le code généré est au moins aussi performant (ça n'est pas nécessairement le cas, la plupart des benchmarks de clang le teste avec un jeu d'instruction moderne (SSE, SSE2, SSSE, ...) mais Haiku est toujours compilé pour une cible 586 (MMX, et rien d'autre) (pour la version x86 uniquement).
Donc, ça fonctionne déjà, mais c'est peu testé, donc il semble raisonable de sortir une version R1 dont on est surs qu'elle est stable et de faire ce changement ensuite (pour la version R1.1 ou R2, par exemple).