Confidentialité et cookies : Notre site utilise des cookies. En continuant à visiter Amiga Impact, vous acceptez leur utilisation. Pour plus d’informations, merci de consulter notre politique de confidentialité.
Politique de confidentialité
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.
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…
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.
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 …
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 …
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.
@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.
@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.
