Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » fxSDK, un SDK alternatif pour écrire des add-ins
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

fxSDK, un SDK alternatif pour écrire des add-ins

Posté le 29/08/2014 22:00

Le fxSDK est une alternative au SDK habituel de Casio. Il permet de développer des add-ins pour la famille de la Graph 35+E et la Graph 90+E, et offre de meilleures performances et plus de possibilités !

Les outils du fxSDK

Le fxSDK marche sous Linux et a été compilé pour Mac OS ; il ne marche pas encore pour Windows mais on peut en discuter.

Il se fonde sur l'indispensable compilateur gcc et sa suite d'outils : as, ld, objdump, objcopy (entre autres). Contrairement au vieux compilateur du SDK, gcc est un compilateur moderne avec beaucoup de possibilités. Il n'est pas fourni avec le fxSDK et fait l'objet d'un tutoriel d'installation à part.

Côté calculatrice, c'est le noyau gint qui fait le travail. Il remplace fxlib 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 !

Le fxSDK fournit également des outils spécifiques pour compiler et étudier les programmes de la calculatrice.

fxsdk est un petit gestionnaire de projet qui vous permet de créer et compiler facilement des projets sans vous prendre la tête avec le Makefile. Parfait si vous ne voulez pas connaître toutes les détails compliqués.

fxg1a sert à créer les fichiers g1a finaux à partir du programme compilé. C'est le successeur de mon vieux g1a-wrapper qui était beaucoup moins puissant.

fxconv convertit des données pour vos add-ins, commes vos images ou polices, dans des formats spécifiques de gint. C'est un peu comme le Sprite Coder mais ça vous évite de copier des gros tableaux dans votre programme et surtout le dessin est beaucoup plus performant !

fxos est un désassembleur et manipulateur d'OS capable de retrouver et disséquer des syscalls en un tour de poignet. C'est un outil de reverse-engineering dont l'usage principal est de produire des listings assembleur annotés pour comprendre très rapidement le code.

Il y a pas mal de différences avec le SDK de Casio donc passer au fxSDK nécessite un peu d'adaptation.

Installer le fxSDK sur votre ordinateur

Ça se passe en trois étapes :

1. Compiler un compilateur gcc à destination de la calculatrice
2. Installer le fxSDK
3. Installer le noyau, gint

Je suppose ici que vous connaissez les bases de la ligne de commande, mais si ce n'est pas le cas, n'hésitez pas à laisser un commentaire pour demander.

La première chose est de vous préparer un cross-compilateur gcc. Vous pouvez sauter l'installation du g1a-wrapper et venir ici dès que la libgcc est installée. Assurez-vous que le compilateur est dans le PATH est vous serez prêt ! C'est le plus gros morceau donc une fois que vous aurez ça, vous aurez déjà pratiquement fini.

Clônez le dépôt git du fxSDK depuis la forge de Planète Casio (vous pouvez aussi utiliser SSH).

% git clone 'https://gitea.planet-casio.com/Lephenixnoir/fxsdk.git'

Configurez le fxSDK ; vous pouvez taper "./configure --help" voir les options disponibles. Par défaut, le fxSDK sera installé dans votre dossier personnel (dans ".local").

% cd fxsdk
% ./configure

Ensuite compilez et installez ! Si vous avez choisi un dossier d'installation différent avec --prefix ou si vous compilez sous Mac, vous pourriez avoir besoin de sudo à l'installation.

% make
% make install

Assurez-vous que votre dossier de destination est dans votre PATH, puis vous pouvez installer gint.

Vous êtes alors prêt à partir !

Développer des programmes avec le fxSDK

TODO: Ajouter l'utilisation de fxsdk.

Toute la partie programmation revient à développer des programmes avec gint. Les tutoriels d'utilisation de gint couvrent tous ce dont vous aurez besoin, y compris l'utilisation de fxconv.


Fichier joint


Précédente 1, 2, 3 ··· 10 ··· 20 ··· 24, 25, 26, 27, 28 Suivante
Dark storm En ligne Membre d'honneur Points: 11355 Défis: 176 Message

Citer : Posté le 15/10/2020 13:05 | #


Sûrement. Un truc qui se fini probablement par /build
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Potter360 En ligne Rédacteur Points: 665 Défis: 0 Message

Citer : Posté le 15/10/2020 13:05 | #


bah alors ca doit etre ca !
Merci !
Hop là... toi qui lis cette signature... tu pourrais aussi aller voir mon projet Elphorina, un jeu de RPG-building !
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

Citer : Posté le 15/10/2020 13:13 | #


Non, un truc qui finit par /bin... c'est dans le tutoriel ça aussi ! x)

% export PATH="$PATH:$PREFIX/bin"
Potter360 En ligne Rédacteur Points: 665 Défis: 0 Message

Citer : Posté le 15/10/2020 13:14 | #


Bon je crois qu'il faut que je lises les tutos plus en detail...
Merci !
Hop là... toi qui lis cette signature... tu pourrais aussi aller voir mon projet Elphorina, un jeu de RPG-building !
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

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
Cakeisalie5 En ligne Ancien administrateur Points: 1828 Défis: 10 Message

Citer : Posté le 17/12/2020 18:03 | #


Yay, un gestionnaire de paquets dans fxsdk

Promotion ordinaire sur les inscriptions sur Planète Casio : en ce moment, c'est gratuit !
Mon blogBesoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

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. >_>
Dark storm En ligne Membre d'honneur Points: 11355 Défis: 176 Message

Citer : Posté le 18/12/2020 15:10 | #


On pourra l'appeler YAPM. Yet Another Packet Manager
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

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.
Kbd2 Hors ligne Membre Points: 239 Défis: 0 Message

Citer : Posté le 22/12/2020 15:07 | #


Now this could be very useful
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

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. ^^"
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

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.

% fxsdk2 repo list -r
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.

Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

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 repo fetch sh-elf-gcc
<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.
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

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 :

<wildcard>:
  <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.

*.png:
  type: bopti-image

libimg_*.png:
  type: bopti-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) :

*.png:
  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.

Quand effectuer la migration : quand vous le voulez.

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.

Instructions de migration

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.
Dark storm En ligne Membre d'honneur Points: 11355 Défis: 176 Message

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 ?
assets/
└── dialogs
    ├── fxconv-metadata.txt
    └── intro.txt

Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

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.
Dark storm En ligne Membre d'honneur Points: 11355 Défis: 176 Message

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
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

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. ^^"
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

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.

Faut-il absolument migrer les projets vers CMake ? Non, si vous gérez votre Makefile.

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.

Instructions de migration

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.

Si votre projet est une bibliothèque gint

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.
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

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.

Quand effectuer la migration : dès la mise à jour de libprof.

Instructions de migration

Remplacer -lprof par -lprof-fx ou -lprof-cg selon la plateforme. Dans project.cfg :

LIBS_FX := -lprof-fx
LIBS_CG := -lprof-cg
Lephenixnoir En ligne Administrateur Points: 19546 Défis: 142 Message

Citer : Posté le 29/01/2021 18:46 | #


Nouvelle version : fxSDK 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!
Précédente 1, 2, 3 ··· 10 ··· 20 ··· 24, 25, 26, 27, 28 Suivante

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2021 | Il y a 71 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd