fxSDK, un SDK alternatif pour écrire des add-ins
Posté le 29/08/2014 22:00
Cette page sert d'index pour la série de topics du fxSDK.
Le fxSDK est une collection d'outils permettant de développer des add-ins pour les calculatrices Casio des séries Graph. C'est une alternative au
fx-9860G SDK et
PrizmSDK qui ne sont plus activement maintenus, et le compagnon classique de mon noyau
gint.
Index des topics
Ce projet existe depuis 2015, alors il y a pas mal de topics liés. En voici une liste complète !
Topics principaux
Installation du fxSDK
Tutoriels
Compatibilité sur calculatrice et PC
Côté PC, le fxSDK est compatible avec
Linux, Mac OS, et WSL pour Windows ; normalement tout le monde peut l'utiliser. Je teste constamment sous Linux, et WSL est un Linux donc c'est testé aussi. Je n'ai pas de Mac OS donc il peut y avoir quelques surprises, mais en général c'est l'affaire de corriger un bug ou deux.
En termes de calculatrices, le fxSDK supporte :
Calculatrices monochromes
Graph 35+E II
Graph 35+ USB / Graph 35+E (SH3/SH4)
Graph 75/75+/75+E
Graph 85/85 SD/95 (SD) (pas activement testé)
Calculatrices couleurs
Graph 90+E / fx-CG 50
Prizm fx-CG 10/20
Comment installer le fxSDK et coder des add-ins
Le fxSDK s'installe à partir de dépôts Git sur la
forge de Planète Casio (par exemple
Lephenixnoir/fxsdk). Il y en a un peu beaucoup, donc manuellement c'est assez long. Pour que ça aille plus vite et pour simplifier le travail des débutants, il y a un outil appelé
GiteaPC qui peut faire ça pour vous.
Si vous utilisez Windows, vous aurez besoin de WSL pour accéder à un système Linux dans Windows. Heureusement, Microsoft a fait ça bien et c'est facile à faire. Voyez le
tutoriel d'installation de WSL 2 (et l'explication rapide de
ce que WSL 2 est).
Si vous utilisez Mac OS, ouvrez l’œil en lisant les topics pour ne pas manquer les informations supplémentaires et éventuelles déviations par rapport à la procédure normale sous Linux.
Méthode automatique avec GiteaPC (plus rapide / recommandée pour les débutants)
- Suivez le tutoriel d'utilisation de GiteaPC, qui explique comment obtenir le fxSDK.
Méthode automatique avec plugin VS Code
- Yannis300307 a créé un plugin VS Code Casio Dev Tools qui fonctionne sous Windows (avec WSL) et Debian (probablement les dérivés aussi).
Méthode AUR pour les utilisateurs Arch/Manjaro/dérivés (ils se reconnaîtront)
- Dark Storm maintient MiddleArch, un dépôt de paquets précompilés qui a entre autres le fxSDK.
Méthode manuelle (plus fine / classique pour les habitués)
- Compilez et installez le cross-compilateur GCC pour SuperH.
- installez (dans cet ordre) les dépôts fxSDK, OpenLibm, fxlibc, gint ; en option, Slyvtt/µSTL_2.3.
Description sommaire du fxSDK
Pour une introduction à l'utilisation du fxSDK qui montre comment utiliser les outils pour développer un add-in, lisez plutôt les
tutoriels d'utilisation de gint. Cette section est juste une description sommaire.
Le cœur du fxSDK est un cross-compilateur GCC pour SuperH, habituellement nommé
sh-elf-gcc. Bien sûr on a avec toute la suite d'outils, dont
as,
ld,
objdump,
objcopy (entre autres). Contrairement au vieux compilateur du SDK, GCC est un compilateur moderne avec beaucoup d'options et capable de très solides optimisations.
Sur la calculatrice, c'est
le noyau gint qui fait la majorité du travail. Il remplace fxlib/libfxcg et une partie de l'OS pour vous offrir des fonctionnalités plus cool et plus rapides. Les add-ins développés avec le fxSDK utilisent gint toutes les trois lignes !
Il y a enfin plusieurs outils utiles sur le PC qui sont utilisés durant le développement ou l'utilisation des add-ins :
- fxsdk est un script shell qui permet de créer et compiler les projets sans se prendre trop la tête. Le système de compilation officiel pour les add-ins est CMake, mais un système plus ancien de Makefile est encore supporté.
- fxconv est un outil très polyvalent qui convertit à la compilation les assets (images, polices, maps....). Il permet de travailler avec des logiciels et formats de fichiers normaux sur le PC et d'avoir automatiquement un format optimisé sur la calculatrice. fxconv est extrêmement extensible et chaque projet peut ajouter des conversions personnalisées.
- fxgxa crée les fichiers g1a (format des add-ins pour Graph monochromes) et g3a (format des add-ins pour Graph couleurs) à partir des programmes compilés.
- fxlink est un outil de communication qui peut transférer des fichiers vers les Graph 35+E II et Graph 90+E en ligne de commande, mais aussi échanger interactivement avec les add-ins gint par le câble USB, et est couramment utilisé pour réaliser des captures d'écran ou captures vidéo des add-ins.
Changelog et informations techniques
Ci-dessous se trouve la liste des posts annonçant les nouvelles versions du fxSDK, ainsi que des liens vers les instructions/tutoriels supplémentaires publiés avec.
Citer : Posté le 15/10/2020 13:05 | #
Sûrement. Un truc qui se fini probablement par /build
Citer : Posté le 15/10/2020 13:05 | #
bah alors ca doit etre ca !
Merci !
Citer : Posté le 15/10/2020 13:13 | #
Non, un truc qui finit par /bin... c'est dans le tutoriel ça aussi ! x)
Citer : Posté le 15/10/2020 13:14 | #
Bon je crois qu'il faut que je lises les tutos plus en detail...
Merci !
Citer : Posté le 17/12/2020 17:49 | #
Je prépare une mise à jour importante du fxSDK qui devrait simplifier toutes les procédures qu'on a actuellement pour l'installer avec gint et les outils qui vont bien.
Actuellement, non seulement GCC est assez compliqué à installer, mais avec mon récent port d'OpenLibm il commence à y avoir plein de libs et tout maintenir devient tordu avec le temps. Idéalement il faudrait tout packager, sauf que d'une part il y a presque autant de distros que d'utilisateurs, et surtout d'autre part c'est beaucoup de boulot, qui retombe ensuite de façon égale sur tous les gens qui écrivent des libs pour gint, ce qui n'est pas très encourageant.
Donc j'ai commencé à réviser le fxSDK pour simplifier tout ça, un peu à la façon du paquet AUR gint-devel-git, mais pour toutes les plateformes et pour toutes les libs en plus de GCC.
Dans l'idée le protocole pour tout installer ressemblera à ça :
• Clôner le dépôt du fxSDK ou le télécharger. Le fxSDK a besoin de python3 et cURL, et c'est tout
• (sudo) make install dans le dépôt du fxSDK
• fxsdk repo install sh-elf-gcc fxconv fxg1a gint # etc
• Répondre à une ou deux questions (pour ajouter GCC au PATH en gros)
• fxsdk project create truc # ... et on est partis
Citer : Posté le 17/12/2020 18:03 | #
Yay, un gestionnaire de paquets dans fxsdk
Promotion ordinaire sur les inscriptions sur
Mon blog ⋅ Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Citer : Posté le 17/12/2020 18:05 | #
C'est pas idéal, on va pas se mentir (j'aime pas trop le concept). Mais étant donné que ça doit être indépendant de la distribution, accessible aux gens qui écrivent juste des libs, et que ça doit tourner sur la forge Gitea, je vois pas de meilleure compromis. >_>
Citer : Posté le 18/12/2020 15:10 | #
On pourra l'appeler YAPM. Yet Another Packet Manager
Citer : Posté le 18/12/2020 15:11 | #
Il s'appellera juste fxsdk2 repo.
Ajouté le 22/12/2020 à 14:56 :
En préparant le troisième tutoriel gint, j'ai remarqué que je pouvais faire une modification sympa à fxconv pour simplifier grandement la génération d'objets personnalisés.
En gros, fxconv peut être étendu avec un script Python (spécifique à chaque projet) pour ajouter des conversion pour des objets personnalisés, typiquement des maps, des animations, des spritesheets, des séquences de dialogue... à peu près tout ce qu'on peut avoir comme assets et qui n'a pas de raison d'être défini comme des grosses variables imbriquées dans le code.
Jusque-là tant qu'on génère que des données brutes ça se passait bien, mais pour générer des pointeurs il fallait sortir les gants et faire un peu d'assembleur. C'est désormais trivial et vraaaiment plus simple qu'avant. (L'assembleur reste supporté.)
Vous verrez les détails dans le tuto gint qui sort demain soir (si j'arrive à rush la programmation et la rédaction) ou après-demain (sinon). Entre ça et la gestion de l'installation ci-dessus, je sens qu'une bonne vague de simplification arrive côté fxSDK.
Citer : Posté le 22/12/2020 15:07 | #
Now this could be very useful
Citer : Posté le 22/12/2020 15:10 | #
Yeah! It doesn't support nesting (... yet) but for most uses you can now create pointer-based structures for a lot of objects without worrying about understanding the memory model and how symbol references are resolved by the linker. Which, I admit, is a pretty high bar to clear just to be able to convert custom maps. ^^"
Citer : Posté le 30/12/2020 18:20 | # |
Fichier joint
Petit aperçu de la compilation de gint avec la prochaine version du fxSDK. Ici je prends mon temps mais on pourrait faire tout ça en une seule commande.
Les dépôts ayant le tag fxsdk sur Gitea sont considérés comme supportés, ils utilisent un mini-Makefile appelé fxsdk.make qui contient des règles pour configure/make/install les configurations de base.
Le fxSDK automatise les tâches courantes (clônage, compilation, installation, mise à jour) mais ne vous empêchera pas d'aller checkout une version de votre choix pour bisect un bug dans une bibliothèque, ni d'utiliser des répertoires hors de son dossier de stockage, ou d'intervenir sur les dépôts de façon générale. Le fxSDK ne garde aucune information et n'utilise que le clône du dépôt, il sert juste à aller plus vite.
Lephenixnoir/OpenLibm (remote)
Fork of the OpenLibm math library with fx-9860G and fx-CG 50 support.
Lephenixnoir/gint (remote)
Alternative library and kernel for add-in development on fx-9860G and fx-CG50 under Linux.
Lephenixnoir/libimg (remote)
A versatile image rendering and transform library.
Lephenixnoir/libprof (remote)
A microsecond-level performance profiling library for gint.
el@realm in ~/Projects/fxsdk2
% fxsdk2 repo fetch gint
<fxsdk2> Cloning Lephenixnoir/gint
el@realm in ~/Projects/fxsdk2
% fxsdk2 repo build gint@master
<fxsdk2> Will build: Lephenixnoir/gint
<fxsdk2> Lephenixnoir/gint: Checking out master
<fxsdk2> Lephenixnoir/gint: Configuring
make: Entering directory '/home/el/.local/share/fxsdk2/repos/Lephenixnoir/gint'
mkdir -p build-fx && cd build-fx && ../configure --target=fx9860g
No prefix specified, let's ask the compiler:
sh-elf-gcc --print-search-dirs | grep install | sed 's/install: //'
Got '/home/el/opt/sh-elf-2.32-9.2.0/lib/gcc/sh3eb-elf/9.2.0/'.
Configuration saved in Makefile.cfg, ready to make!
mkdir -p build-cg && cd build-cg && ../configure --target=fxcg50
No prefix specified, let's ask the compiler:
sh-elf-gcc --print-search-dirs | grep install | sed 's/install: //'
Got '/home/el/opt/sh-elf-2.32-9.2.0/lib/gcc/sh3eb-elf/9.2.0/'.
Configuration saved in Makefile.cfg, ready to make!
make: Leaving directory '/home/el/.local/share/fxsdk2/repos/Lephenixnoir/gint'
<fxsdk2> Lephenixnoir/gint: Building
make: Entering directory '/home/el/.local/share/fxsdk2/repos/Lephenixnoir/gint'
make all
make[1]: Entering directory '/home/el/.local/share/fxsdk2/repos/Lephenixnoir/gint'
:: Making into build-cg
> gcc rtc/rtc.c
> as rtc/inth.s
(...)
> ar libgint-cg.a
:: Making into build-fx
> as render-fx/topti-asm.s
> as render-fx/bopti-asm-mono-scsp.s
(...)
> ar libgint-fx.a
make[1]: Leaving directory '/home/el/.local/share/fxsdk2/repos/Lephenixnoir/gint'
make: Leaving directory '/home/el/.local/share/fxsdk2/repos/Lephenixnoir/gint'
<fxsdk2> Lephenixnoir/gint: Done! :D
Notez qu'en vrai c'est coloré pour qu'on s'y retrouve plus facilement, ça ressemble plus au truc ci-dessous.
Citer : Posté le 30/12/2020 23:28 | # |
Fichier joint
J'ai une première version pour un GCC automatisé, que voilà. Je ne sais pas encore exactement comment l'installation de fxsdk2 se fera, mais j'ai fait attention à minimiser les dépendances pour que ce soit facile (que Python3 et Git). Il y aura bien sûr la méthode propre pour ceux qui veulent prendre le temps, et sans doute un curl | bash pour ceux qui veulent juste faire marcher le truc et se moquent qu'une VM ou un Ubuntu WSL se fasse compromettre. x3
<fxsdk2> Cloning Lephenixnoir/sh-elf-gcc
% fxsdk2 repo build sh-elf-gcc
<fxsdk2> Will build: Lephenixnoir/sh-elf-gcc
<fxsdk2> Lephenixnoir/sh-elf-gcc: Configuring
<sh-elf-gcc> Downloading https://ftp.gnu.org/gnu/binutils/binutils-2.35.1.tar.xz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 21.0M 100 21.0M 0 0 8682k 0 0:00:02 0:00:02 --:--:-- 8679k
<sh-elf-gcc> Downloading https://ftp.gnu.org/gnu/gcc/gcc-10.2.0/gcc-10.2.0.tar.xz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 71.5M 100 71.5M 0 0 17.7M 0 0:00:04 0:00:04 --:--:-- 17.7M
<sh-elf-gcc> Extracting binutils-2.35.1.tar.xz...
<sh-elf-gcc> Extracting gcc-10.2.0.tar.xz...
<fxsdk2> Lephenixnoir/sh-elf-gcc: Building
<sh-elf-gcc> Configuring binutils...
<sh-elf-gcc> Compiling binutils (can take a couple of minutes)...
<sh-elf-gcc> Configuring gcc...
<sh-elf-gcc> Compiling gcc (often takes 10-20 minutes)...
<sh-elf-gcc> Cleaning up...
<fxsdk2> Lephenixnoir/sh-elf-gcc: Done! :D
C'est toujours un peu dur à lire donc voilà une autre capture (f2r est mon alias pour fxsdk2 repo).
Si des dépendances de GCC manquent, le script proposera de les installer via pacman ou apt. Lors de l'installation (pas affichée ici), il proposera aussi de mettre à jour le PATH dans .profile (et quelques variantes). Autant que possible j'essaie de faire ça newbie-proof. ^^"
Ajouté le 02/01/2021 à 15:57 :
Suite aux recommandations de Breizh, j'ai sorti le gestionnaire de dépôts comme un outil indépendant. Ça ne change rien pour vous, c'est juste plus propre pour le code et pour les gens qui veulent packager.
Les infos sont donc sur le topic du nouvel outil GiteaPC, je reviendrai ici quand j'aurai un tutoriel d'installation du fxSDK à base de GiteaPC. Ça ne devrait pas tarder !
Ajouté le 07/01/2021 à 12:05 :
J'ai eu quelques retours de bugs aujourd'hui (dont un que je viens de corriger).
Je sais que l'état actuel du SDK est pas idéal (il y a quelques problèmes en cours avec l'installation et l'entretien), et c'est en partie à cause du fait que j'ai appris au fur et à mesure de l'existence de l'outil les problématiques qui se posaient pour les développeurs d'add-ins, la publication des mises à jour, le maintien des dépôts, les procédures d'installation...
Tout ça est vraiment plus compliqué que ça en a l'air.
Je ne serai vraiment pas satisfait d'un SDK qui n'est pas propre, accessible et dénué de bugs, et je concentre (là tout de suite) mes efforts pour résoudre sur le long terme les problèmes que vous avez pu rencontrer. Parmi ces problèmes, on trouve :
• Difficultés à compiler GCC, installer le fxSDK, installer gint ou les libs. GiteaPC doit aider à faire ça.
• Désynchronisation des versions entre plusieurs outils, quand c'est moi qui fait des bêtises. Ça ne se produira plus.
• Désynchronisation des versions entre plusieurs outils, quand vous n'avez pas tout recompilé. GiteaPC saura mettre automatique à jour.
• Migration de versions : faut-il recompiler gint avec make ou make -B ? Faut-il recompiler vos projets avec fxsdk build-cg ou avec make -B all-cg ? Une meileure gestion des dépendances éliminera cette question.
La raison pour laquelle ces changements n'arrivent que maintenant est que vos projets doivent pouvoir suivre. Par exemple, il faudra certainement modifier le Makefile dans vos projets. Ce genre de migration est casse-pieds pour vous et je fais de mon mieux pour (1) en faire le moins souvent possible, et (2) préparer le SDK pour que vous n'ayez pas besoin d'intervenir dans le futur.
Voilà voilà pour la situation.
Ajouté le 22/01/2021 à 14:23 :
J'ai beaucoup progressé sur les questions de compilation. En plus de passer le fxSDK à GiteaPC, j'ai commencé avec gint aussi.
J'expérimente avec l'idée de compiler gint avec CMake, ce qui ne change rien pour vous mais aide beaucoup pour les développeurs. CMake est conçu pour permettre de partager du code à la façon de bibliothèques, et c'est comme ça que le fxSDK fournit les outils pour compiler sur la calculatrices aux projets utilisant CMake. Le fxSDK fournit des "modules CMake" pour utiliser gint, pour utiliser fxconv, et je suis encore en train d'en ajouter un pour obtenir des numéros de version à partir de Git.
Comme tous ces modules sont installés par le fxSDK, une mise à jour du fxSDK mettra automatiquement à jour vos projets après avoir reconfiguré. C'est une amélioration très importante sur le fxSDK actuel, où le Makefile du fxSDK est copié dans votre dossier de projet et le mettre à jour est compliqué pour moi et pour vous.
Citer : Posté le 29/01/2021 15:22 | #
La publication du fxSDK 2.3 arrive sous peu, voici les premiers éléments de changelog. Le message de release indiquera comment mettre à jour le fxSDK et le contexte de ce message.
Spécification des paramètres de conversion pour fxconv (fxSDK 2.3)
Jusqu'ici, les paramètres pour fxconv étaient spécifiés à la fin de project.cfg avec un format peu intuitif, et le type des assets était indiqué par le sous-dossier de assets-{fx,cg} où ils se trouvaient : fonts, img, bin principalement.
Ce mécanisme est remplacé par une nouvelle méthode plus élégante (et polyvalente). Les paramètres sont maintenant spécifiés dans des fichiers fxconv-metadata.txt à côté des assets. Le type est spécifié en même temps que les paramètres, donc le choix des sous-dossiers n'importe plus. De plus, les sous-dossiers à des niveaux arbitraires sont maintenant supportés.
Le format de fxconv-metadata.txt est une liste de spécifications avec cette syntaxe :
<nom1>: <valeur1>
<nom2>: <valeur2>
# etc
Les paramètres listés s'appliquent à tous les fichiers du dossier dont le nom valide le wildcard. Les paramètres sont appliqués de haut en bas. Par exemple, le fxconv-metadata.txt suivant convertit toutes les images PNG du dossier avec bopti, sauf celles dont le nom commence par libimg_, qui sont converties avec libimg.
type: bopti-image
libimg_*.png:
type: libimg-image
Le nom de variable pour chaque asset doit maintenant être spécifié (avant, il était déduit du nom du fichier). On peut le faire individuellement en indiquant le paramètre name, ou en groupe en spécifiant name_regex avec en premier lieu une regex à matcher sur le nom du fichier et en second lieu le nom de variable correspondant. Par exemple, le fxconv-metadata.txt suivant nomme toutes les images à la façon du système précédent (img_nom_du_fichier) :
type: bopti-image
name_regex: (.*)\.png img_\1
Si name et name_regex sont spécifiés tous les deux, name a la priorité. Autres exemples : [1], [2].
L'ancien système est toujours supporté : les anciennes commandes fxconv fonctionnent toujours, le mode automatique n'est activé que si aucun type n'est spécifié sur la ligne de commande. Voyez le commit et le message d'aide pour les détails.
Vos projets actuels utilisent un Makefile, et tant que ce Makefile ne change pas, l'ancien système (qui est toujours supporté) continuera de fonctionner. Vous pouvez mettre à jour le fxSDK et vous occuper de cette migration plus tard. Cependant, si vous voulez utiliser CMake, vous devrez faire cette migration avant.
Si vous souhaitez migrer votre projet sous CMake, effectuez uniquement les étapes 2 et 3. Les modules CMake fournis par le fxSDK utilisent déjà le nouveau système, donc les autres seront faites durant le passage à CMake.
1. Mettez à jour votre Makefile avec le nouveau Makefile du fxSDK (c'est le seul changement en plus de l'ajout des flags DSP).
2. Créez assets-{fx,cg}/img/fxconv-metadata.txt comme ceci :
type: bopti-image
name_regex: (.*)\.[^.]+ img_\1
3. Créez assets-{fx,cg}/fonts/fxconv-metadata.txt comme ceci :
type: font
name_regex: (.*)\.[^.]+ font_\1
4. Supprimez le bloc "File conversion parameters" à la fin de project.cfg.
5. Recompilez avec make -B.
Citer : Posté le 29/01/2021 16:18 | #
Ah chouette, ça sera moins la croix et la bannière pour setup les options.
Par contre deux remarques
– img_\1 vs img_$1 ?
– fxconv-metadata.txt vs fxconv.conf ou metadata.conf ?
Pour ce second cas, si j'ai un dossier comme ça, c'est foireux non ?
└── dialogs
├── fxconv-metadata.txt
└── intro.txt
Citer : Posté le 29/01/2021 16:57 | #
Merci ! Pour le \1 c'est la syntaxe Python (voir la documentation de re.sub()), je ne peux pas trop la changer. Je peux envisager un remplacement automatique, même si ça ne change pas grand-chose à la fin.
Pour fxconv-metadata.txt, je ne voulais pas risquer d'utiliser une extension qui sous-entend un format comme INI ou clé=valeur, donc je suis parti sur .txt. J'aurais pu prendre un nom plus court mais pourquoi faire court quand on peut faire clair ?
Enfin, ta dernière question revient à la détection des assets.
• Dans le Makefile, les fichiers nommés fxconv-metadata.txt (et seuls ceux-là) sont exclus de la recherche, et sont un nom d'asset invalide.
• Dans CMake, la bonne pratique est de lister les fichiers sources toi-même. Mais si tu veux glob (j'indiquerai comment dans le tutoriel) tu peux faire pareil et retirer les fichiers en fonction de leur nom.
Citer : Posté le 29/01/2021 16:59 | #
Looks legitimate.
Mouais, je trouve que le .txt est sémantiquement du texte, pas de la conf. J'entends ton point de vue, mais à ce moment là est-ce que l'extension est vraiment utile ? fxconv-metadata peut suffire, en plus d'être plus court
Citer : Posté le 29/01/2021 17:02 | #
Disons que c'est moins pratique si tu utilises un navigateur de fichiers graphique (double-cliquer sur un fichier sans extension ne donnera pas forcément un éditeur de texte), que tu télécharges le fichier depuis un navigateur ou que tu l'utilises sous Windows (la porte n'étant pas fermée à un portage). Personnellement je trouve que .txt est une extension correcte pour tous les fichiers texte génériques, après tout c'est bien un fichier texte. Un peu comme Arch a des paquets en .pkg.tar.zst et pas .archpkg.
Bon si ça fait débat je veux pas m'embêter avec, voilà juste le raisonnement derrière. ^^"
Citer : Posté le 29/01/2021 17:26 | #
Et voici le gros morceau de cette release.
Support de CMake comme système de compilation (fxSDK 2.3)
Le Makefile qui existe actuellement a un problème : il est copié et poussé sur les dépôts même quand les développeurs ne le maîtrisent pas forcément. C'est un problème, car comme il est copié toute modification doit passer par vous, et si vous ne maîtrisez pas un peu GNU make, ça se complique très vite.
CMake résoud ce problème de deux façons : d'une part il est plus facile à appréhender pour les débutants, d'autre part il permet au fxSDK de fournir des outils de compilation qui ne sont pas dans votre dépôt, mais dans le dossier d'installation du fxSDK. Cet aspect modulaire de CMake permet aussi d'élaborer significativement les outils de compilation.
Je vous conseille vivement de lire le tutoriel de compilation d'add-ins avec CMake, qui sert d'introduction à CMake pour les débutants et couvre les aspects spécifiques au fxSDK.
L'ancien système à Makefile continue et continuera d'être supporté. Mais il ne bénéficiera pas de mise à jour automatiques (... comme jusqu'à présent en fait), et votre intervention sera nécessaire pour chaque mise à jour. D'autres fonctionnalités optionnelles, comme la détection des versions depuis le dépôt Git pour les add-ins et bibliothèques (ici), ne sont implémentées que pour CMake.
Si vous ne lisez jamais votre Makefile et voulez surtout que ça marche sans trop vous poser de questions, je vous conseille de passer à CMake.
Les projets du fxSDK sont désormais créés pour CMake sauf si vous indiquez --makefile à fxsdk new.
1. Créez un fichier CMakeLists.txt dans votre dépôt avec le CMakeLists.txt par défaut du fxSDK (que vous pouvez aussi obtenir à partir d'un projet vierge).
2. Dans votre CMakeLists.txt, indiquez la liste de vos fichiers source dans le set(SOURCES), la liste de vos assets spécifiques à la Graph mono dans set(ASSETS_fx) et la liste des assets spécifiques à la Graph 90+E dans set(ASSETS_cg).
3. Dans generate_g1a() et generate_g3a(), modifiez le nom du fichier g1a ou g3a que vous voulez (après OUTPUT), le nom de votre add-in (après NAME), et le nom de vos fichiers d'icônes (icon-fx.png, icon-cg-sel.png et icon-cg-uns.png dans les anciens projets).
4. Si vous utilisez des bibliothèques, ajoutez les find_package() correspondants et les cibles dans le target_link_libraries(). Des détails sont donnés dans le tutoriel d'utilisation de CMake et sur les dépôts des bibliothèques (par exemple libprof). Si votre bibliothèque n'utilise pas CMake, vous pouvez ajouter -lthing à target_link_libraries() directement.
5. Migrez vos assets vers le nouveau système de paramètre fxconv. Il s'agit essentiellement de créer quelques fichiers fxconv-metadata.txt pour remplacer la fin de project.cfg.
6. Si vous avez fait des changements importants à votre Makefile, c'est le moment d'ajuster. Si le tutoriel CMake ne vous permet pas de le faire, n'hésitez pas à demander sur ce topic.
7. Supprimez les dossiers build-fx et build-cg et recompilez avec fxsdk build-fx et/ou fxsdk build-cg. Si vous avez une erreur qui vous échappe, n'hésitez pas à demander sur ce topic. Si vous avez la possibilité de partager une archive de votre projet ou de le pousser sur Gitea, ça aidera beaucoup.
8. Supprimez Makefile et project.cfg, et c'est fini.
Dans ce cas-là il y a un peu plus de travail, il faut également modifier les instructions d'installation. Je présume que vous savez utiliser GNU make si vous en êtes arrivés là. Vous pouvez trouver un exemple de bibliothèque gint avec CMake dans le dépôt Lephenixnoir/Template-gint-library et vous en inspirer pour adapter le système de compilation.
Citer : Posté le 29/01/2021 18:38 | #
Quelques autres détails.
Modification des flags de libprof
En passant à CMake, libprof a été séparée en libprof-fx et libprof-cg (même si le code est le même), donc les flags ont changé.
Ce problème ne concerne que les projets utilisant un Makefile, puisque lorsque CMake est utilisé c'est la bibliothèque elle-même qui fournit les options donc vous n'avez pas à vous en soucier.
Remplacer -lprof par -lprof-fx ou -lprof-cg selon la plateforme. Dans project.cfg :
LIBS_CG := -lprof-cg
Citer : Posté le 29/01/2021 18:46 | #
Release associée de gint : gint 2.3.0
Et voici la version 2.3 du fxSDK. C'est une version très orientée vers la distribution, pour rendre plus facile le partage des outils, programmes et bibliothèques, et la gestion des projets. J'espère que vous y trouverez votre compte, toute l'intention est de vous aider et/ou simplifier la vie.
Cette version arrive aussi avec GiteaPC qui fait le plus gros du boulot pour utiliser et mettre à jour des bibliothèques en deux coups de clavier. Je vous suggère d'y jeter un oeil, vous pourriez tourner avec tout à jour en 5-10 minutes.
Trois tutoriels accompagnent cette version :
• Utilisation de GiteaPC pour gérer un environnement de développement
• [Tutoriel] Compiler des add-ins avec CMake (fxSDK)
• Lephenixnoir/Template-gint-library d'écrit l'utilisation du fxSDK et de CMake pour créer une bibliothèque gint
Voici les détails des changements !
Nouveautés
• Ajouté un système plus élégant de conversion pour fxconv. Explications et instructions de migration.
• Ajouté le support de CMake comme système de compilation. Tout l'écosystème fxSDK bénéficie de ce support, j'ai par exemple modifié mes libs en conséquence. Explications et instructions de migration.
• Ajouté des modules CMake utilitaires : pour déterminer la version d'un projet à partir des tags et commits Git, et pour faciliter l'écriture de Find<Package>.cmake pour les bibliothèques
Changements
• libprof est désormais séparée en libprof-fx et libprof-cg. Brèves instructions de migration.
• La commande fxsdk update a été supprimée, les mises à jour de Makefile étant toujours plus compliquées qu'une simple copie. Si vous voulez éviter de vous y intéresser, considérez l'utilisation de CMake, qui est plus simple à comprendre et à gérer pour les débutants.
• fxg1a donnera toujours un nom interne (celui de la forme @ADDIN) correct donc ce n'est plus la peine de le spécifier. De toute façon personne ne s'en sert, c'était juste un coup à se planter de format (ce qui rend l'add-in invisible sur le menu principal).
• fxsdk new ne demande plus d'informations interactivement. Pour les Makefile il choisit des valeurs par défaut sensibles (à modifier dans project.cfg), pour CMake vous devez modifier CMakeLists.txt (dans lequel vous devez déjà ajouter les fichiers source etc).
• fxsdk new a une nouvelle option --makefile pour générer des Makefile (par défaut il utilise CMake).
Ajouté le 29/01/2021 à 19:36 :
Les instructions d'utilisation de GiteaPC ont été mises à jour avec des instructions spécifiques pour la création et la migration d'environnements de développement fxSDK/gint, ce qui conclut cette release (à quelques détails près).
Enjoy!