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 » GiteaPC : Installer et mettre à jour automatiquement des projets Gitea
Lephenixnoir En ligne Administrateur Points: 19373 Défis: 142 Message

GiteaPC : Installer et mettre à jour automatiquement des projets Gitea

Posté le 01/01/2021 23:19

Pour pallier aux difficultés d'installation du fxSDK sous Linux, j'ai réfléchi à créer un outil pour automatiquement installer et mettre à jour des projets depuis le dépôt Gitea. L'outil est encore jeune donc les tests sont bienvenus, mais le développement est a priori complet.

» Code source : dépôt Lephenixnoir/GiteaPC «

Qu'est-ce que GiteaPC fait ?
• Clôner, configurer, compiler et installer en une ligne des projets depuis le dépôt Gitea.
• Dans une certaine mesure, installer aussi les dépendances (les versions ne sont pas suivies).
• Metre à jour en une ligne une installation du fxSDK avec des bibliothèques.

Quels projets peuvent bénéficier de GiteaPC ?
• Le compilateur GCC pour la calculatrice, le fxSDK avec ses outils, gint.
• Toutes les bibliothèques de programmation d'add-ins, gint ou pas, écrites par n'importe qui.
• De façon générale, tout outil mis à la disposition de la communauté : p7, des utilitaires de conversion, des éditeurs de maps...

Qu'est-ce qu'on y gagne ?
• C'est plus rapide de laisser le script automatique tourner que de faire le tutoriel.
• Pour les débutants, c'est plus simple de prendre des valeurs par défaut sensibles sans se casser la tête.
• Pour les experts, vous gardez le contrôle de tout les dépôts pour faire des manigances (voir ci-dessous).

Merci pour les conversations avec notamment Breizh_craft, Dark Storm et Cakeisalie5 qui m'ont bien aidé à cerner un design plus élégant.

Installation

Il y a des dépendances à installer évidemment. Voici la commande pour les distributions les plus communes sur PC ; cmake est nécessaire pour gint et les bibliothèques qui vont avec, et conseillé pour utiliser le fxSDK.

# Debian, Ubuntu, Ubuntu dans WSL, Linux Mint, dérivés de Debian :
% sudo apt install curl git python3 build-essential cmake

# ArchLinux, Manjaro, dérivés d'ArchLinux :
% sudo pacman -S curl git python3 gcc make cmake

L'installation en une ligne de GiteaPC se fait avec la commande suivante :

% curl "https://gitea.planet-casio.com/Lephenixnoir/GiteaPC/raw/branch/master/install.sh" -o /tmp/giteapc-install.sh && bash /tmp/giteapc-install.sh

Vous pouvez consulter le script ici ou faire l'installation manuelle depuis le dépôt Lephenixnoir/GiteaPC si vous préférez ça.

Vous aurez probablement besoin de mettre à jour votre PATH. Si vous ne connaissez pas le PATH ou avez du mal à le situer, vous pouvez lire le Tutoriel du Mercredi #20 sur ce sujet. Si ça se produit, GiteaPC vous demandera de modifier le PATH en ces termes :

<giteapc> In order to use programs installed by GiteaPC, you will need to add their
<giteapc> install folder to your PATH. This can be done automatically when you log
<giteapc> in by adding the following command to your startup file:
<giteapc>
<giteapc>   export PATH="$PATH:/home/el/.local/bin"
<giteapc>
<giteapc> -> Press Enter to add this command to /home/el/.profile, or
<giteapc> -> Type another file name to add this command to, or
<giteapc> -> Type "-" to skip setting the PATH entirely.
>

Si vous n'utilisez pas votre .profile, .bashrc ou équivalent (ou ne savez pas ce que c'est), appuyez sur Entrée puis fermez et rouvrez votre session (ou redémarrez votre ordinateur). Si vous utilisez .profile ou équivalent, alors vous comprenez certainement la question, faites ce que vous préférez.

Pour vérifier que l'installation a fonctionné, lancez la commande giteapc. Vous devez obtenir un message d'aide coloré avec la liste des commandes. giteapc peut se mettre à jour tout seul donc vous n'aurez plus besoin de refaire ce travail d'installation.

Obtenir ou migrer une installation du fxSDK avec GiteaPC

Le fxSDK et toutes les libs qui vont avec (que je gère, du moins) peuvent être distribuées avec GiteaPC. Vous pouvez obtenir un environnement de développement avec gint et le fxSDK avec la commande ci-dessous.

giteapc install Lephenixnoir/sh-elf-binutils:any Lephenixnoir/sh-elf-gcc:any Lephenixnoir/fxsdk Lephenixnoir/gint

Cela installera un cross-compilateur GCC à jour, sauf si vous en avez déjà un, auquel cas celui que vous avez est utilisé. Ensuite ça installera le fxSDK et gint, c'est-à-dire tout ce qu'il vous faut pour commencer à coder des add-ins.

Si vous avez déjà une installation du fxSDK, vous avez deux choix.
• Ou bien vous gardez votre compilateur et vous gardez les :any dans la commande.
• Ou bien vous recompilez GCC, pour ça enlevez les :any et supprimez votre ancien GCC après avoir fini l'installation.

À court terme à ça revient au même, à long terme (1-2 ans) tout le monde devra probablement recompiler GCC à cause des évolutions.

Le fxSDK dépend aussi de la bibliothèque Python PIL (pour manipuler des images) :

# Debian, Ubuntu, Ubuntu dans WSL, Linux Mint, dérivés de Debian :
% sudo apt install python3-pil

# ArchLinux, Manjaro, dérivés d'ArchLinux :
% sudo apt install python-pillow

Une fois l'installation réalisée avec GiteaPC, vous pouvez supprimer vos anciens clônes des dépôts. Vous pouvez toujours consulter les clônes de GiteaPC avec la commande suivante (par exemple pour le fxSDK) :

cd $(giteapc show -p Lephenixnoir/fxsdk)

Enrichir et mettre à jour une installation du fxSDK avec GiteaPC

Pour installer un nouveau dépôt qui supporte GiteaPC, par exemple la bibliothèque libprof, utilisez giteapc install.

giteapc install Lephenixnoir/libprof

Vous pouvez tout mettre à jour avec giteapc install -u. GiteaPC vous autorise à donner les noms des dépôts sans leur propriétaire s'il n'y a pas d'ambiguïté, ce qui est un peu risqué quand il s'agit des dépôts distants (à l'installation) mais pas trop quand il s'agit de dépôts locaux (durant une mise à jour).

giteapc install -u sh-elf-binutils sh-elf-gcc fxsdk gint libprof

Et voilà, tout est à jour.

Instructions d'utilisations plus précises

Lister et rechercher des dépôts

Utilisez giteapc list -r pour lister les dépôts de la forge qui peuvent être installés avec Gitea, et giteapc list pour lister tous les dépôts que vous avez sur votre ordinateur.

Si un argument supplémentaire est donné, il servira à filtrer par nom et par description. Par exemple, giteapc list -r gcc.

Installer et mettre à jour des dépôts

Utilisez giteapc install pour installer un dépôt et giteapc install -u pour mettre à jour un dépôt. La différence c'est qu'avec -u les nouveautés seront téléchargées avant l'installation (git pull).

Installer des versions spécifiques

Les noms des dépôts dans les commandes install et build acceptent deux suffixes : @version et :config (dans cet ordre). Le premier permet de sélectionner (git checkout) une branche ou un tag. Le second permet de modifier les options de compilation si le dépôt en supporte (par exemple binutils et GCC ont une configuration « any » qui accepte tout GCC déjà installé et ne compile pas s'ils en trouvent un).

Par exemple, pour installer spécifiquement binutils 2.35.1, on peut utiliser la commande ci-dessous. Notez que du coup le dépôt est figé à la version 2.35.1 et ne sera pas mis à jour (même avec -u) tant que vous n'installerez pas explicitement sh-elf-binutils@master pour revenir sur la branche principale.

giteapc install Lephenixnoir/sh-elf-binutils@2.35.1

Pour installer binutils mais utiliser une version déjà installée l'an dernier sans le recompiler, on peut utiliser la configuration « any ».

giteapc install Lephenixnoir/sh-elf-binutils:any

Commandes fines

giteapc fetch permet de clôner ou mettre à jour (git fetch) un dépôt sans toucher à rien.
giteapc build permet de configure/build un dépôt sans l'installer ou de recompiler sans reconfigurer.
giteapc show permet de voir les versions disponibles d'un dépôt local ou distant.

Voyez l'aide (giteapc --help) pour le détail des options.

Désinstaller un dépôt

giteapc uninstall désinstalle un dépôt et supprime le clône local, giteapc uninstall -k déinstalle le dépôt mais garde le clône local. Les dépendances ne sont pas vérifiées durant une désinstallation donc gardez un œil dessus.

Créer un projet supportant GiteaPC

Pour pouvoir être installé par GiteaPC, un dépôt doit avoir les choses suivantes :

• Le topic giteapc sur le dépôt (qu'on peut ajouter en cliquant sur le lien "Manage topics" sur la page principale du dépôt) : c'est ce qui permet au dépôt d'apparaître dans giteapc list -r.

• Fournir un giteapc.make qui contient quelques métadonnées, qui inclut optionnellement giteapc-config.make et fournit quatre cibles configure, build, install et uninstall (plus de détails ci-dessous).

• Avoir giteapc-config.make et giteapc-config-*.make dans le .gitignore.

giteapc-config.make sera un lien symbolique pointant vers la configuration courante et giteapc-config-*.make sont les configurations à proprement parler. Si vous en fournissez par défaut, retirez-les explicitement (!giteapc-config-myconf.make). Tous les autres noms doivent être ignorés pour que l'utilisateur puisse ajouter ses propres configurations sans que le dépôt casse à chaque pull à cause des fichiers non traqués.

Le giteapc.make doit ressembler à ça :

# giteapc: version=1
# giteapc: depends=Lephenixnoir/sh-elf-gcc

-include giteapc-config.make

configure:
    ...
build:
    ...
install:
    ...
uninstall:
    ...

.PHONY: configure build install uninstall


D'abord les métadonnées ; il y en a deux pour l'instant : version (doit être "1") et depends (liste des dépendances). Ensuite l'inclusion optionnelle de giteapc-config.make. Et enfin, les règles configure, build, install et uninstall, dans lesquelles vous pouvez lancer le code qui va bien.

Quelques exemples : sh-elf-gcc, fxsdk, Template-gint-library.

Usage et intérêt pour les experts

Pour pas mal de dépôts et situations, les paramètres par défaut conviennent, donc l'usage de GiteaPC a (je pense) un intérêt pour tout le monde. J'espère pouvoir délivrer un maximum de contenu par un minimum de canaux pour simplifier la complexité des projets qu'on a aujourd'hui sous Linux.

La vision de GiteaPC est uniquement d'accélérer les choses qu'on aurait faites de toute façon. C'est donc conçu pour qu'on puisse prendre la main à tout moment. Concrètement :

• GiteaPC ne fait qu'exécuter des commandes git et make (et quelques requêtes à la forge Gitea).
• L'outil ne stocke et ne cache aucune information externe, donc si vous jouez avec les dépôts entre deux utilisations il suivra sans se poser de questions.
• Vous pouvez checkout, compiler, bisect, trifouiller, manipuler les dépôts à votre guise. (Il n'y a que le risque habituel de décorréler la version checked-out du dépôt et la version installée.)
• Vous pouvez aussi créer des liens symboliques du dossier de stockage de GiteaPC vers vos dossiers de projet pour tester des outils sans avoir à les pousser constamment sur la forge.

Comme vous pouvez le voir, c'est plein de possibilités !


1, 2, 3 Suivante
Lephenixnoir En ligne Administrateur Points: 19373 Défis: 142 Message

Citer : Posté le 02/01/2021 00:17 | # | Fichier joint


Breizh prévient que ce ne sera pas un prétexte pour créer des dépôts avec des méthodes d'installation bordéliques cachées par l'automatisation.


Du reste, j'ai terminé sh-elf-binutils (la première moitié du tuto GCC) et je suis sur le point de finir GCC. Si vous regardez sur #dev vous verrez tous les dépôts y passer.

Ajouté le 02/01/2021 à 00:24 :
Et voilà sh-elf-gcc qui est bon. La prochaine étape c'est de peaufiner des parties de GiteaPC qui me manquent et je publie le code avec de quoi l'installer.

Je testerai systématiquement sur Arch et sur des Debians vierges pour vérifier que ce soit robuste.

Ajouté le 02/01/2021 à 11:32 :
Pour information, avec cet outil l'installation du compilateur, fxSDK, gint sur un système vierge devrait ressembler à ça.

D'abord installer GiteaPC :

% curl "https://gitea.planet-casio.com/.../install.sh" | bash

Le script demandera de mettre à jour le PATH, comme d'habitude c'est presque le plus compliqué... à voir si je peux faciliter ça...

Et ensuite on installe tout.

% giteapc install Lephenixnoir/sh-elf-gcc Lephenixnoir/fxsdk Lephenixnoir/gint

Et là on peut commencer à coder.
Potter360 Hors ligne Rédacteur Points: 619 Défis: 0 Message

Citer : Posté le 02/01/2021 11:33 | #


Et ca ce serai pour tout ? (Cross-compilateur GCC, Fxsdk et Gint)
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: 19373 Défis: 142 Message

Citer : Posté le 02/01/2021 11:34 | #


Oui. Si tu regardes c'était même écrit tout en haut :

Quels projets peuvent bénéficier de GiteaPC ?
• Le compilateur GCC pour la calculatrice, le fxSDK avec ses outils, gint.
• ...
Potter360 Hors ligne Rédacteur Points: 619 Défis: 0 Message

Citer : Posté le 02/01/2021 11:36 | #


Ah oui donc vachement plus facile que l'autre installation...
Trop hâte !
Hop là... toi qui lis cette signature... tu pourrais aussi aller voir mon projet Elphorina, un jeu de RPG-building !
Dark storm En ligne Membre d'honneur Points: 11324 Défis: 176 Message

Citer : Posté le 02/01/2021 11:48 | #


Pas mal.
Quelques questions :
- Comment tu compte gérer le problème des dépendances ?
- Est ce que le dossier d'installation est modifiable ? Idem pour celui de clonage
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 19373 Défis: 142 Message

Citer : Posté le 02/01/2021 11:56 | #


Merci ! <3

Pour les dépendances tu as un truc très primitif où tu peux indiquer un nom ; par exemple, Lephenixnoir/sh-elf-gcc dépend de Lephenixnoir/sh-elf-binutils. Si tu installes un dépôt, il installe aussi ses dépendances (master). Si tu veux la dépendance sous une autre version, tu peux l'installer avant :

giteapc install sh-elf-binutils@2.35.1 sh-elf-gcc

Quand tu mets à jour il pull les dépendances (mais si c'est un tag ça aura pas d'effet).

Quand tu supprimes, les dépendances ne sont pas touchées. Et les versions ne sont pas suivies.

J'ai hésité à le faire complètement mais j'ai été retenu par deux raisons :
• D'une part, ça fait beaucoup de code et de complexité ajoutée (maintenir l'arbre des dépendances) pour pas trop de bénéfices vu que tout est un peu en rolling release ici.
• D'autre part ça m'aurait obligé à me souvenir de quelle version de chaque dépôt était installée, et je ne voulais surtout pas stocker des informations à côté pour qu'on puisse toucher à la main aux dépôts sans que ça casse l'outil.

Pour le dossier d'installation des dépôts, tu peux faire deux choses. La première est de modifier GITEAPC_HOME (par défaut : ~/.local/share/giteapc) qui est le dossier où les dépôts sont téléchargés. Si tu veux maintenir deux "installations" tu peux jouer là-dessus. Mais comme GiteaPC ne va chercher les dépôts que là, tu peux difficilement avoir gint dans un dossier et libprof dans un autre.

La deuxième chose que tu peux faire est simplement de créer des liens symboliques, par exemple tu peux créer un lien de $GITEAPC_HOME/Darks/libtouhou vers ~/Projects/libtouhou et ce sera géré correctement. C'est très pratique pour tester l'installation sans avoir à pousser sur la forge.

Le dossier d'installation de GiteaPC est personnalisable aussi, il suffit je pense de faire curl ... | PREFIX=... bash et ça ira (c'est un poil plus propre si tu installes à la main).
Dark storm En ligne Membre d'honneur Points: 11324 Défis: 176 Message

Citer : Posté le 02/01/2021 15:00 | #


Mmmh, merci pour les explications.

Pour ce qui est des dépendances, j'ai pas été assez clair je pense. J'ai vu que tu récupère la liste des dépendances depuis le giteapc.make. Est-ce que tu peux ajouter des tags à ces dépendances ? Parce que c'est typiquement le problème aujourd'hui, ie un projet utilise une certaine version d'une lib, qui elle-même dépend d'une version précise d'une autre, etc.

Typiquement Touhou ne compile pas si tu utilises la suite fxsdk/gint/libxxx depuis leurs branches master respectives.

J'aime pas le fait de devoir fixer une version précise sur un projet (ce qu'on peut retrouver avec pipenv par exemple), mais le cycle de release autour de ces projets étant tellement rapide que c'est un coup à se retrouver avec un tas de dépôts qui compilent plus parce qu'on se sait pas quelles versions de dépendances sont requises pour que ça fonctionne.

À minima pouvoir utiliser les tags fait qu'un projet reste compilable (malgré des optis manquantes, etc.) même si on le reprend 3 ans plus tard.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 19373 Défis: 142 Message

Citer : Posté le 02/01/2021 15:07 | #


Hmm... je peux faire depends=Lephenixnoir/gint@2.1.0 mais ça va te poser des problèmes parce que l'installation de Touhou (en supposant qu'on veuille l'installer via GiteaPC) descendra gint à la version 2.1, ce qui n'est certainement pas acceptable pour tout le reste du monde.

Je pense que ce problème n'est pas spécifique à GiteaPC : si ton environnement de développement est bloqué à gint 2.1, tout un paquet de choses finira par casser. Tu peux le faire, mais je préfère t'en laisser la responsabilité :

giteapc install Lephenixnoir/gint@2.1.0
# Installation : la dépendance existe, elle sera utilisée telle quelle
giteapc install Darks/Touhou
# Update : la dépendance est pull, mais le tag n'a pas bougé : aucun changement
giteapc install -u Darks/Touhou

Je suis pas trop hyper chaud por intégrer la version dans les dépendances, à cause du risque un peu casse-pieds que quelqu'un qui tente d'installer ton programme sans savoir se retrouve avec une lib coincée dans une vieille version. Dans l'exemple précédent la branche master ne sera pull que si tu spécifies exactement Lephenixnoir/gint@master un jour, et quelqu'un qui ne s'est pas rendu compte du problème pourra casser ses projets perso un bon moment avant de tenter ça.

Avec les options que je vois, le plus "stable" reste de faire écrire la version à l'auteur dans le README.

Ajouté le 02/01/2021 à 15:25 :
J'ai ajouté les sources et les instructions d'installation !
Potter360 Hors ligne Rédacteur Points: 619 Défis: 0 Message

Citer : Posté le 02/01/2021 19:05 | #


Lephenixnoir a écrit :
J'ai ajouté les sources et les instructions d'installation !

Pour Gint, GCC et le FXSDK ?
Si oui, ou ?
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: 19373 Défis: 142 Message

Citer : Posté le 02/01/2021 19:23 | #


Pour GiteaPC. Je suis encore en train d'améliorer les scripts pour GCC/binutils pour résoudre des problèmes que des gens ont rencontré par le passé, donc tout n'est pas fini encore.

Si tu veux savoir quand tu pourras installer gint et le fxSDK avec, surveille l'apparition d'un tuto d'installation sur le topic du fxSDK
Potter360 Hors ligne Rédacteur Points: 619 Défis: 0 Message

Citer : Posté le 02/01/2021 19:23 | #


Ok merci !
Hop là... toi qui lis cette signature... tu pourrais aussi aller voir mon projet Elphorina, un jeu de RPG-building !
Dark storm En ligne Membre d'honneur Points: 11324 Défis: 176 Message

Citer : Posté le 02/01/2021 21:00 | #


J'ai fait quelques réflexions à voix haute sur la shout, j'essaie de résumer ça ici.

J'ai peur qu'en l'état giteapc n'ait qu'une faible valeur ajoutée.

En premier lieu l'outil ne permet pas de se séparer complètement du terminal, il faut quand même savoir au moins se déplacer, lancer une commande au bon endroit, faire un make pour compiler son nouveau projet. À partir du moment où on sait faire ça, on sait généralement faire un git clone; make; make install. Dans tous les cas il faut que le makefile du projet en question soit propre. L'avantage de giteapc dans ce cas est de gagner 15 secondes et de gérer les dépendances automatiquement (mais pas exactement, j'y reviendrais).

En deuxième lieu, l'installation de GCC/binutils sur toute distro n'ayant pas l'AUR était ce qui posait le plus problème. J'ai résolu ça à l'arrache avec un script, et Lephe proprement avec les deux dépôts sur la forge. Dans tous les cas le mieux resterait un paquet propre pour la distro, mais bon, personne n'a la motivation de le faire pour Debian, donc bon…

En troisième lieu, Giteapc ne propose pas d'environnement virtuel pour gérer les dépendances de chaque projet distinctement. Comme je disais au dessus, vu le rythme de développement soutenu deux projets utilisent rarement les mêmes versions, et même gint/fxsdk sont pas toujours compatibles sur leurs branches master.
Sur ce dernier point, je vois plusieurs axes d'amélioration :
– bien mettre des tags sur les bibliothèques dès qu'on fait une modif sur master
– si une version de dev est prête à être utilisée, lui coller un tag avec le suffixe -<prerelease> (alpha, beta, indev, ...)
– indiquer chaque version utilisée quand on fait un projet, dans le readme par exemple

Je verrais une vraie valeur ajoutée si giteapc permet de faire des environnements virtuels, avec le fonctionnement suivant :
1. on installe un projet, les dépendances taguées sont récupérées, compilées et installées dans un dossier .env dans le dossier du projet
2. on active l'environnement virtuel, .env est ajouté au PATH de manière temporaire
3. make → le projet est compilé sans prise de tête
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 19373 Défis: 142 Message

Citer : Posté le 02/01/2021 23:33 | #


En premier lieu l'outil ne permet pas de se séparer complètement du terminal, il faut quand même savoir au moins se déplacer, lancer une commande au bon endroit, faire un make pour compiler son nouveau projet.

Pour ce qui est d'installer GiteaPC et installer des dépôts, ce n'est pas le cas : tu n'as pas besoin d'avoir un dossier spécifique sous la main. Si tu suis les instructions tu peux tout faire depuis ~ et tu n'auras aucun résidu indésirable. La compétence nécessaire c'est juste de copier-coller les commandes pour commencer à coder.

À partir du moment où on sait faire ça, on sait généralement faire un git clone; make; make install. Dans tous les cas il faut que le makefile du projet en question soit propre. L'avantage de giteapc dans ce cas est de gagner 15 secondes et de gérer les dépendances automatiquement (mais pas exactement, j'y reviendrais).

L'installation du fxSDK requiert bien plus que trois commandes ; rien que sur la compilation de GCC, le tuto actuel et ton script sur l'AUR se plantent à un endroit important (la détection de binutils) et je ne suis même pas sûr de pourquoi ils marchent. Les scripts d'installation pour GiteaPC simplifient bel et bien un processus d'installation compliqué en plus de le rendre bien plus rapide.

Quant au clone/make, je ne suis pas d'accord non plus. Savoir faire clone/make est une chose, clôner le fxSDK, gint, libprof, libimg, OpenLibm, la liblog de Milang et ton moteur de jeu favori, surveiller les nouveautés de chacun, les mettre à jour régulièrement en faisant git pull dans chaque dépôt et recompiler dans le sens contraire des dépendances à chaque fois est une purge. Savoir faire n'est pas le problème ; là aussi la question est d'automatiser une tâche fastidieuse.

Dans tous les cas le mieux resterait un paquet propre pour la distro, mais bon, personne n'a la motivation de le faire pour Debian, donc bon…

Je ne suis pas d'accord là non plus. Le packaging ce n'est pas le boulot des devs, et packager gcc/gint pour Debian ne résoud aucun problème :

• Nemhardy utilise Void Linux, d'autres utiliseront des distros exotiques, et je veux pas passer ma vie à ajouter des cibles Makefile pour créer des paquets pour des distributions que j'ai jamais vues. Toutes les distros n'ont pas un AUR non plus, les dépôts non officiels pour Debian c'est pas aussi simple que pour Arch, il faut héberger le PPA quelque part (et si tu héberges sur Launchpad le truc est lié à compte etc etc etc).

• La gestion des paquets Debian est très complexe et pas rapide du tout. L'autre jour j'ai déclaré des dépendances manquantes à libgiac-dev, il a fallu 24 jours pour que les dépendances apparaissent quand tu fais apt install libgiac-dev. C'est justement une des raisons pour lesquelles pip/npm/etc existent.

• Chaque plateforme à cibler rend infiniment compliqué le travail de quiconque veut publier une lib gint. Si avec tout le temps que je passe là-dessus je veux pas gérer les paquets ne t'attends pas à voir quelqu'un d'autre franchir le pas.

Comme je disais au dessus, vu le rythme de développement soutenu deux projets utilisent rarement les mêmes versions, et même gint/fxsdk sont pas toujours compatibles sur leurs branches master.

Les problèmes de compatibilité sur mes branches master sont entièrement de ma faute et je compte bien le régler en même temps que je publie le tutoriel d'installation/mise à jour à base de GiteaPC, notamment en versionnant mes libs sur le même schéma que gint pour qu'il soit plus simple de trouver les versions compatibles.

Maintenant je ne suis pas non plus d'accord avec le fait de simplement fixer tes versions et oublier ce qui se passe ensuite. Depuis les bêtas de la version 2 je publie des notes de migration et je minimise les changements à toutes les APIs pour réaliser (même si je ne garantis pas formellement) un maximum de stabilité.

– si une version de dev est prête à être utilisée, lui coller un tag avec le suffixe -<prerelease> (alpha, beta, indev, ...)

Spoiler : déjà fait – 2.0.3-beta, 2.0.4-rc.

Je verrais une vraie valeur ajoutée si giteapc permet de faire des environnements virtuels

Mon opinion sur les environnements virtuels est la même que pour Flask sur la v5, s'il y a un problème de gestion de versions il faut s'attaquer à ça et pas freeze le système, ce qui n'est pas une solution. Sans vouloir être méchant ici, je ne me souviens pas que tu m'ai demandé des infos sur des changements de gint que tu aurais ratés, et fixer les versions c'est un peu la solution flemmarde.

Libre à toi de te faire un environnement virtuel, ça ne prend que quelques lignes de plus que la liste des versions :

export GITEAPC_HOME="$(pwd)/.env/repos"
export GITEAPC_PREFIX="$(pwd)/.env/prefix"

mkdir -p "$(GITEAPC_HOME)" "$(GITEAPC_PREFIX)"
export PATH="$GITEAPC_PREFIX/bin:$PATH"

giteapc install sh-elf-binutils@2.35.1 sh-elf-gcc@10.2.0
giteapc install fxsdk@1.0 gint@2.1.0 openlibm@1.0

make all-fx all-cg

Mais je ne veux pas supporter ça parce que ça contredit mon objectif de n'avoir dans GiteaPC qu'un outil transparent pour accélérer ce qu'on aurait de toute façon fait à la main, et mon objectif de garder mes utilisateurs synchronisés avec des versions stables de mes libs.
Dark storm En ligne Membre d'honneur Points: 11324 Défis: 176 Message

Citer : Posté le 03/01/2021 00:15 | #


La compétence nécessaire c'est juste de copier-coller les commandes pour commencer à coder.

Faut à minima :
– connaître le principe du dossier courant
– savoir se déplacer depuis $HOME vers $HOME/Projets/mystère-noir-et-blanc

Les scripts d'installation pour GiteaPC simplifient bel et bien un processus d'installation compliqué en plus de le rendre bien plus rapide.

Je suis bien d'accord. Mon point concerne GiteaPC et pas les scripts développés pour.

Savoir faire clone/make est une chose, clôner le fxSDK, gint, libprof, libimg, OpenLibm, la liblog de Milang et ton moteur de jeu favori, surveiller les nouveautés de chacun, les mettre à jour régulièrement en git pull dans chaque dépôt et recompiler dans le sens contraire des dépendances à chaque fois est une purge

C'est pas non plus si fréquent. Mais oui, tu gagne 15 secondes par dépôt, donc 2 minutes à tout casser, une fois par mois environ. Et ça n'empêche pas de devoir suivre les évolutions de tes libs préférées vu que GiteaPC ne fait pas d'update automatique, et encore moins de refacto en cas de mise à jour d'API.

Nemhardy utilise Void Linux, d'autres utiliseront des distros exotiques

Quand tu utilise une distro exotique, tu sais comment construire le soft à la main, et souvent tu préfère le faire à la main parce que t'as ta propre manière de gérer ton système. Non pas que GiteaPC soit inutile dans ce cas de figure, juste qu'il sera peu utilisé.
+1 pour le packaging Debian, même si je parlais uniquement de GCC en l'occurence, et pas de chacun des projets annexes.

Chaque plateforme à cibler rend infiniment compliqué le travail de quiconque veut publier une lib gint.

Je ne vois pas en quoi. Les libs actuelles sont déjà compatibles avec tous les systèmes… Suffit d'avoir un makefile propre pour que ça soit pas une purge. Comme disait Breizh, faut pas que ça devienne une excuse pour faire de la merde.


En ce qui concerne la gestion des versions, je suis assez mitigé. D'une part c'est vraiment cool le boulot que t'a fait sur le sujet, d'autre part tu ne peux pas de manière réaliste forcer l'upstream vu la vitesse à laquelle tu développe. Fixer la version c'est aussi s'assurer qu'un projet soit compilable 2 ans plus tard, même si ça peut se faire dans un readme à la rigueur.
Je veux bien faire le pari de l'upstream sur master, mais j'ai peur qu'à un moment où un autre ça casse pas mal de trucs parce que tout ne va pas à la même vitesse (soutenue).

De toute façon, on verra à l'usage…
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 19373 Défis: 142 Message

Citer : Posté le 03/01/2021 00:38 | #


Faut à minima :
– connaître le principe du dossier courant
– savoir se déplacer depuis $HOME vers $HOME/Projets/mystère-noir-et-blanc

Si tu ne sais pas faire ça ou ne peux pas apprendre à le faire, ce n'est pas la peine d'essayer de créer des add-ins. Les bases de la ligne de commande sont plus simples que la compilation d'une lib hébergée sur Gitea : il suffit de lire les topics pour s'en convaincre. Entre les headers manquants parce que les dépendances sont pas installées, les outils manquants ou pas dans le PATH, savoir localiser le message d'erreur dans ce qui s'affiche sur le terminal, git pull qui échoue parce qu'un fichier a été modifié ou parce que des binaires sont traqués, sans même parler de régler le problème rien que comprendre la nature de l'erreur est difficile. Mon objectif est d'abaisser cette difficulté-là (qui est plus difficile que les bases de la programmation C), pas celle de savoir utiliser un shell.

Je suis bien d'accord. Mon point concerne GiteaPC et pas les scripts développés pour.

Diffuser et maintenir les scripts est une question non triviale en soi, qui bien qu'annexe mérite d'être abordée aussi. Ce qui est le cas pour toutes les libs, m'amenant à :

C'est pas non plus si fréquent. Mais oui, tu gagne 15 secondes par dépôt, donc 2 minutes à tout casser, une fois par mois environ. Et ça n'empêche pas de devoir suivre les évolutions de tes libs préférées vu que GiteaPC ne fait pas d'update automatique, et encore moins de refacto en cas de mise à jour d'API.

Non, non. D'une part si se tenir à jour n'était pas si fréquent tu n'insisterais pas autant sur le fait que je "développe vite" (ce que je conteste, cf. ci-dessous) pour justifier de ne pas utiliser la dernière version de gint.

D'autre part tu sous-estimes vraiment la tâche que ça représente. Les gens qui installent gint n'arrivent pas tous à installer libprof du premier coup. Et après il faut aussi installer libimg. Et aussi OpenLibm. Et je n'ai pas l'intention de fusionner toutes ces libs donc ça ne va pas s'améliorer. Et quand tu mets à jour gint il faut aussi les mettre à jour si elles sont concernées, et recompiler tes projets (parfois avec make -B, parfois pas), des fois le format des fichiers change donc il faut mettre à jour fxconv aussi...

C'est compliqué pour moi (d'où le desync fxSDK/gint), ce n'est pas facile pour l'utilisateur moyen.

Je ne vois pas en quoi. Les libs actuelles sont déjà compatibles avec tous les systèmes… Suffit d'avoir un makefile propre pour que ça soit pas une purge. Comme disait Breizh, faut pas que ça devienne une excuse pour faire de la merde.

Alors pourquoi est-ce que Touhou ne tourne (d'après ce que tu dis) pas sur la dernière version de gint ? Comment veux-tu que les devs avec des compétences modestes fassent quand ils utilisent gint avec 3 libs ce que toi-même tu ne fais pas avec gint et aucune lib ? x)

D'une part c'est vraiment cool le boulot que t'a fait sur le sujet, d'autre part tu ne peux pas de manière réaliste forcer l'upstream vu la vitesse à laquelle tu développe. Fixer la version c'est aussi s'assurer qu'un projet soit compilable 2 ans plus tard, même si ça peut se faire dans un readme à la rigueur.

Quelle vitesse ? La version 2.1.0 date d'il y a 5 mois, et depuis il n'y a eu aucun changement sur l'API de la 2.1.0, à part un pixel vertical et demi-pixel horizontal de positionnement sur DTEXT_CENTER. Le reste, c'est des extensions (mais ça le code d'il y a 5 mois s'en fout) et des changements internes (donc le desync fxSDK/gint). Il n'y a même eu aucun commit pendant deux mois après le tag 2.1.0 !

La réalité c'est que j'ai fait de mon mieux (même si je peux me planter) pour que le code d'il y a 5 mois compile toujours à l'identique aujourd'hui, et je n'ai eu aucun retour disant le contraire...

Ajouté le 03/01/2021 à 17:27 :
Suite à une suggestion/remarque maline de Darks, je vais me débrouiller pour GiteaPC puisse se mettre à jour avec le temps. Ça ne coûte pas grand-chose et ça permettra de délivrer des mises à jour de l'outil si jamais il y en a.
Caillou15 En ligne Membre Points: 55 Défis: 0 Message

Citer : Posté le 06/01/2021 19:03 | #


J'essaie d'installer ce nouveau système qui m'a l'air intéressant et pourrais me permettre de ne plus galérer pour utiliser gint.
J'ai exécuté le curl mais quand je fais la commande suivante, ça me dit

sudo: /etc/sudoers is world writable
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

Est-ce que vous connaissez une solution à ce problème ? J'ai un peu cherché sur internet mais tout ce que jj'ai trouvé ne fonctionne pas.
Je rappelle que je suis avec WSL.
Je suis lycéen en Terminale donc il faudra peut-être attendre avant d'avoir une réponse de ma part à cause du travail. Et je n'y connais rien à Linux, j'utilise Windows (avec WSL si besoin)
Lephenixnoir En ligne Administrateur Points: 19373 Défis: 142 Message

Citer : Posté le 06/01/2021 19:17 | #


Hmm y'a un problème avec ton sudo. Dans l'absolu c'est « pas ma faute », mais faudrait voir si c'est le cas de tous les gens qui utilisent WSL.

J'ai pas tout à fait fini avec GiteaPC, si tu veux une installation durable je te conseille d'attendre quelques jours avant de tout installer.
Cakeisalie5 En ligne Ancien administrateur Points: 1821 Défis: 10 Message

Citer : Posté le 06/01/2021 19:20 | #


Ce n'est effectivement pas la faute de GiteaPC, mais une installation peut-être hâtive de sudo. Tentes un su puis, dans le nouveau shell, chmod 600 /etc/sudoers, ça devrait faire le taf.

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: 19373 Défis: 142 Message

Citer : Posté le 08/01/2021 10:46 | #


Après avoir cherché quelques jours la bonne sémantique pour l'outil, je pense être arrivé à un bon compromis.

Si vous ne connaissez pas les problèmes autour de l'installation et la mise à jour de logiciels, en voici un petit aperçu. La plupart des difficultés proviennent du fait que les différents dépôts que vous utilisez ne sont généralement pas synchronisés, et donc il faut d'une part les garder à jour en même temps, et d'autre part ne pas paniquer s'il y en a un qui ne marche plus (par exemple une erreur de compilation parce que le développeur a commis une erreur).

L'idée de GiteaPC est de faire automatiquement ce que vous auriez fait à la main, les problèmes sont donc les mêmes que si vous arrangez les choses à la main.

• Le premier problème à l'installation est l'oubli de dépendances. La plupart des programmes ne marchent pas tous seuls et utilisent d'autres programmes, des bibliothèques, ou des outils extérieurs. On appelle ces éléments extérieurs des dépendances. Si les dépendances ne sont pas installées alors l'outil ne peut pas fonctionner. GiteaPC aide à éviter les dépendances manquantes avec des déclarations basiques de dépôts nécessaires, et en vérifiant les paquets système nécessaires dans les scripts.

Une gestion suffisante des dépendances garantit que vous aurez toujours tous les outils dont vous avez besoin pour travailler.

Mais ce n'est pas tout, car tous ces programmes évoluent, il y en a plusieurs versions. Je pousse régulièrement du nouveau code dans les miens, par exemple. Et il est évident que le fxSDK d'il y a 2 ans est totalement incompatible avec le gint d'aujourd'hui. Il faut donc s'organiser pour utiliser des versions compatibles.

• La façon la plus naturelle est de toujours utiliser la dernière version de tout. Avec GiteaPC, par défaut l'installation d'un dépôt donne la dernière version stable (la branche master). GiteaPC ne met jamais à jour dans votre dos (pour ne pas casser votre code !) mais la simple commande giteapc install -u met tous les dépôts à jour vers la dernière version.

• Bien sûr il serait impensable de vous empêcher d'utiliser des versions plus anciennes. GiteaPC le permet en spécifiant un numéro de version, par exemple gint@2.1.0. Par contre à ce moment-là vous vous devez pour débrouiller pour installer aussi les versions compatibles des autres outils (par exemple le fxSDK). Il n'est jamais trop tard pour réinstaller ensuite gint@master et faire une mise à jour complète.

Tout cela vous permet donc, dans les cas simples, d'avoir automatiquement tous les outils nécessaires dans la bonne version.

En plus de ça, il faut prendre un compte un certain nombre de scénarios pragmatiques. Que faire si un dépôt échoue durant la compilation ou l'installation ? Que faire si vous voulez modifier une bibliothèque pour debugger un problème ou tester une nouvelle fonctionnalité ? Que faire si vous êtes le développeur de la bibliothèque ?

J'ai aussi prévu ces cas.

• GiteaPC ne stocke aucune information en-dehors des dépôts. Ça veut dire que vous pouvez modifier les dépôts, changer le code, la version, recompiler, et ça ne lui posera pas de problème. Attention simplement, si vous laissez traîner des fichiers non enregistrés dans un commit et pas ignorés par le dépôt, les futurs git pull risqueront d'échouer.

• Une conséquence de ça c'est que GiteaPC ne sait pas quelle version de chaque outil est installée (comme vous, la plupart du temps ; cette information n'est pas suivie). L'outil recompilera toujours les dépendances et les dépôts lors des mises à jour, donc si un dépôt à échoué à la compilation dans le passé il échouera de nouveau (plutôt que de prendre la version déjà installée qui ne serait pas à jour, ce qui sera catastrophique). Comme exception utile, sh-elf-binutils et sh-elf-gcc détectent s'ils sont déjà installés dans la bonne version et ne se recompileront pas si ce n'est pas nécessaire.

• Vous pouvez aussi créer un lien symbolique de dossier où GiteaPC stocke les dépôts vers un de vos projets perso (par exemple je lie ~/.local/share/giteapc/Lephenixnoir/fxsdk vers ~/Projects/fxsdk) pour tester en local un de vos dépôts. Cela me permet de tester l'installation du fxSDK via GiteaPC sans avoir à pousser sur la forge. De plus, comme le fxSDK est toujours à jour, je peux juste taper giteapc install -u pour recompiler tous mes dépôts et vérifier qu'ils sont compatibles quand je fais des changements. Pareil quand je modifie gint et le fxSDK, une seule commande réinstalle immédiatement les deux (j'en oublie tout le temps au moins un).

Tout ça n'est pas parfait, mais je pense un bon compromis pour les programmes et les développeurs. Le procédé pour créer un dépôt installable avec GiteaPC est aussi très accessible, donc j'espère que ça encouragera tout le monde à créer et partager des bibliothèques. o/
Dark storm En ligne Membre d'honneur Points: 11324 Défis: 176 Message

Citer : Posté le 08/01/2021 11:08 | #


Ça commence à prendre forme, c'est cool

GiteaPC ne sait pas quelle version de chaque outil est installée

En soit tu peux récupérer l'état avec un git status (ou équivalent). Je n'ai pas vu si tu le fais déjà, mais ça peut être intéressant d'avoir le diff quand tu fais un update ou un changement de branche. Genre « sur le tag v1.2.3, vous allez passer sur la branche master. Aucune modification détectée, le pull devrait fonctionner ».
Là c'est peut-être un peu verbeux, mais tu peux afficher un warning dans le cas où tu fais un pull et qu'un fichier suivi a été modifié.

Lephe, sur la shout a écrit :
Pour le diff, il est affiché tout seul par Git quand on pull (je laisse sortir son stdout sur le terminal).

L'avantage de checker à la main avant, c'est que tu peux lever une erreur qui sera peut-être plus compréhensible par le public visé par l'outil.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
1, 2, 3 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 79 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