Cela faisait bien longtemps que le kit de développement pour MorphOS n’avait pas été mis à jour au-delà des fichiers includes.
Une nouvelle version du kit de développement a été rendu disponible pour test. Ce SDK comporte de nombreuses nouveautés :
- Compilateurs
Oui, avec un s ! En effet, le SDK dispose maintenant de deux compilateurs GCC. Il s’agit de la version 2.95.3 déjà connue de longue date, mais avec une grosse nouveauté : celle-ci peut compiler du code Altivec !Un second compilateur est disponible, il s’agit toujours de GCC, mais en version 4.4.4, version très récente.
- MorphED
Editeur du SDK, il n’est pas en reste concernant les nouveautés. Le développement d’interface utilisateur sur MorphOS est censé être réalisé en utilisant MUI. Ainsi l’éditeur MorphED se voit mis à jour :- Coloration syntaxique étendues pour MUI
- Aide rapide étendue pour toutes les classes MUI
- Documentation
La documentation bouge également. En effet, de nombreuses additions ont été réalisées. De nombreux guides en provenance de l’univers AROS ont été revus, corrigés et augmentés toutefois il est conseillé de se tourner de préférence vers la documentation originale de Commodore concernant les appels ‘legacy’ de la version 3.1 du système.
Télécharger : MorphOSSDK_2b.lha [26,7 Mo]
15 Commentaires
Passer au formulaire de commentaire
Deux compilateurs C ? Cela va pas compliquer ?
GeekGadgets, c’est quoi exactement ? Il y a quelques années, un truc du même nom était dispo sur un CD de Dream et il me semblait que c’était un serveur X…
@Screetch:
Non cela ne complique pas (trop) et encore moins maintenant car le 4.x cohabite très bien avec le 2.95.3.
Dans le SDK il y a même un petit script permettant de redéfinir sur quelle version pointent les binaires ‘par-défauts’ non versionés (genre gcc, g++, …).
De base les binaires sont préfixés par ‘ppc-morphos-‘
et postfixés par le numéro de version.
Sinon, Geekgadgets est un ensemble de répertoires et de fichiers permettant de simuler un environment Unix.
Et c’est là que se trouve tous les outils de compilation, les fichiers des ‘include’ et le bibliothèques statiques.
Est-ce qu’il y a un débogueur ?
Seul le 2.95 permet l’Altivec ou le 4.4 aussi ?
La coloration syntaxique est utilisable sous GoldEd ?
A++
@Sarag: kprintf() ? 😀
@Vince:
1) les deux
2) oui (GoldED ~= MorphED)
Et pour info, le 4.x supporte aussi le mode baserel (r13)
Excellent ! Je me demandais justement où trouver le SDK pour MorphOS 2.x.
Bravo à celui qui a implémenté le support de l’AltiVec dans GCC 2.95.3 … il faut être motivé ! Déjà pour mettre le nez dans GCC et ensuite pour ses connaissances en AltiVec.
Yomgui : Je ne suis pas sûr que répondre kprintf pour déboguer rassure Sarag …
@Corto: sérieux, on peut débugger autrement? 😀
Yomgui : Sérieux, oui, on devrait … en 2010 ! Le kprintf, ça fonctionne mais c’est long, fastidieux, …
Mais je sais qu’écrire un débogueur n’est pas une mince affaire …
C’est normal que GCC 4 se plaigne du signe des charactères (typedef de STRPTR) ?
Cela a été implémenté par les gars de Motorola… 🙂
@centaurz: oui GCC4 est nettement plus grincheux que ces prédécesseurs (cela vaut d’ailleurs beaucoup de travail aux gens qui codent avec leurs pieds…)
Ici il va falloir utiliser ceci en option de gcc:
-Wno-pointer-sign
Edit: Où bien utiliser -funsigned-char car bien souvent (cf include std) les proto des fonctions et le code utilisent ‘char *’ pour les buffers.
Mais cela aura un effect de bord avec d’autres warnings si jamais tu utilisent char * et que ton code attend réellement d’opérer en signé.
Donc ma première solution est la meilleurs si jamais tu veux pas (ou peux pas) modifier le code.
Les débogueurs font effectivement partie des outils qui sont utilisés dans le monde entier pour mettre au point les programmes.
Si la Morphos Team souhaite par idéologie mépriser les développeurs qui en verraient une utilité, et bien soit.
Je salue par contre des deux mains l’arrivée officielle de GCC4.
Dire la vérité (« non il n’y a pas ») n’est pas mépriser. Ta réaction par contre…
@sarag: comme henes je ne comprend pas tes mots.
Un outils comme gdb il y en a pas, il y en a jamais eu et si personne ne si met il n’y en aura jamais! D’où mon ironie avec le kprintf! Car je fais tout avec… (enfin dprintf en faite, mais c’est un autre sujet).
La MOS-Team est une très petite équipe face à la quantité de logiciels et de travail à faire (le SDK2 a demander beaucoup d’efforts par exemple).
Les programmeurs ne doivent pas penser que les choses tombent dans le bec comme ça. Au contraire cela demande de gros et lourds investissements personnels.
Le problème c’est qu’à chaque fois que je demande simplement si un portage est en cours, un membre de la MOS Team se paye de ma tête en m’expliquant que ça ne sert à rien. Du coup j’ai un peu les boules, connaissant l’intérêt d’avoir des outils de dev corrects pour booster une plateforme.
Dommage qu’à l’époque ou Frank Wille avait commencé un portage de gdb, qq’un lui ait dit que ça ne servait à rien, qu’une version allait arriver…
Maintenant, je suis ravi de voir arriver un SDK plus sympa pour ceux qui en ont besoin. C’est juste dommage que j’en aie eu marre avant.