GiteaPC : Installer et mettre à jour automatiquement des projets Gitea
Posté le 01/01/2021 23:19
Ce topic fait partie de la série de topics du fxSDK.
GiteaPC est un programme Python qui automatise l'installation de projets de la
la forge Git de Planète Casio. Son usage principal est d'installer et mettre à jour le
fxSDK de façon automatique.
Le code source est sur le dépôt Git
Lephenixnoir/GiteaPC. Merci notamment à
Breizh_craft,
Dark Storm et
Cakeisalie5 qui m'ont bien aidé à cerner un design plus élégant.
Installation de GiteaPC
Pour Mac OS : GiteaPC fonctionne, mais il y a quelques ajustements à faire. Voyez
le guide de Choukas.
Il y a quelques dépendances à installer. Voici la commande pour les distributions les plus communes sur Planète Casio : copiez la commande (la ligne après le
%) dans un terminal puis appuyez sur Entrée (votre mot de passe sera demandé).
# Si vous avez Debian, Ubuntu, WSL sous Windows, Linux Mint ou d'autres dérivés de Debian :
% sudo apt install curl git python3 build-essential cmake pkg-config
# Si vous avez Arch Linux, Manjaro, ou d'autres dérivés d'Arch Linux :
% sudo pacman -S curl git python3 gcc make cmake pkgconf
Ensuite vous pouvez installer GiteaPC en une ligne avec la commande suivante :
% curl "https://git.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.
Installation du fxSDK avec GiteaPC
Le fxSDK et toutes les bibliothèques qui vont avec (que je gère, du moins) peuvent être obtenues avec GiteaPC. Le fxSDK dépend de quelques bibliothèques dont vous aurez besoin (même formule que précédemment, attention à bien copier la commande complète d'un coup même si elle s'affiche sur plusieurs lignes) :
# Debian, Ubuntu, WSL sous Windows, Linux Mint, dérivés de Debian :
% sudo apt install python3-pil libusb-1.0-0-dev libudev-dev libsdl2-dev libpng-dev libncurses-dev
# En option pour fxlink -s :
% sudo apt install libudisks2-dev libglib2.0-dev
# ArchLinux, Manjaro, dérivés d'ArchLinux :
% sudo pacman -S python-pillow libusb sdl2 ncurses patch
# En option pour fxlink -s :
% sudo pacman -S udisks2
Avec ces dépendances, vous pouvez obtenir un environnement de développement avec gint et le fxSDK en quelques étapes. Prenez garde aux cas particuliers suivants :
- Si jamais vous avez déjà une version de binutils/GCC installée après le fxSDK 2.9 et que vous ne voulez pas les recompiler (ce qui prend ~30 minutes), vous pouvez ajouter :any après Lephenixnoir/sh-elf-binutils et Lephenixnoir/sh-elf-gcc.
- Si votre Linux n'utilise pas UDisks2 comme gestionnaire de périphériques (vous pouvez tester si la commande udisksctl existe), ajoutez :noudisks2 après Lephenixnoir/fxsdk. Cela désactivera l'option -s de fxlink qui utilise UDisks2 pour copier des fichiers vers les Graph 35+E II et Graph 90+E depuis la ligne de commande.
- Si vous avez déjà une installation du fxSDK installée sans GiteaPC ou avant la version fxSDK 2.9, vous devez la supprimer avant de commencer, sinon tout va interférer et ce sera le chaos !
Cela étant vu, on commence par installer les outils principaux du fxSDK et le cross-compilateur. Pendant qu'on y est, on installe aussi le debugger (optionnel) :
% giteapc install Lephenixnoir/fxsdk Lephenixnoir/sh-elf-binutils Lephenixnoir/sh-elf-gcc
% giteapc install Lephenixnoir/sh-elf-gdb
Ensuite on installe la lib mathématique, la libc, et on repasse sur GCC pour obtenir la lib C++ :
% giteapc install Lephenixnoir/OpenLibm Vhex-Kernel-Core/fxlibc
% giteapc install Lephenixnoir/sh-elf-gcc
Et enfin on installe gint (et si vous le voulez d'autres libs) :
% giteapc install Lephenixnoir/gint # Lephenixnoir/libprof Slyvtt/cZlib1_2_5 ...
À partir de là vous pouvez coder des add-ins.
Vous pouvez toujours consulter les dépôts clonés par GiteaPC avec la commande
giteapc show -p :
cd $(giteapc show -p Lephenixnoir/fxsdk)
Si vous voulez juste coder avec le fxSDK, jetez un œil à la section suivante pour les mises à jour puis vous pouvez arrêter de lire. Le reste de ce topic parle des détails de GiteaPC, qui ne sont pas importants pour juste programmer des add-ins.
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 discutée précédemment).
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 au bon endroit 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 dans le
.gitignore.
giteapc-config.make sera un lien symbolique pointant vers la configuration courante, laquelle sera nommée
giteapc-config-X.make pour
:X.
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 de
giteapc-config.make quand une configuration est demandée. 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.
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 :
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.
Et là on peut commencer à coder.
Citer : Posté le 02/01/2021 11:33 | #
Et ca ce serai pour tout ? (Cross-compilateur GCC, Fxsdk et Gint)
Citer : Posté le 02/01/2021 11:34 | #
Oui. Si tu regardes c'était même écrit tout en haut :
• Le compilateur GCC pour la calculatrice, le fxSDK avec ses outils, gint.
• ...
Citer : Posté le 02/01/2021 11:36 | #
Ah oui donc vachement plus facile que l'autre installation...
Trop hâte !
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
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 :
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).
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.
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é :
# 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 !
Citer : Posté le 02/01/2021 19:05 | #
J'ai ajouté les sources et les instructions d'installation !
Pour Gint, GCC et le FXSDK ?
Si oui, ou ?
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
Citer : Posté le 02/01/2021 19:23 | #
Ok merci !
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
Citer : Posté le 02/01/2021 23:33 | #
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.
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.
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.
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é.
Spoiler : déjà fait – 2.0.3-beta, 2.0.4-rc.
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_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.
Citer : Posté le 03/01/2021 00:15 | #
Faut à minima :
– connaître le principe du dossier courant
– savoir se déplacer depuis $HOME vers $HOME/Projets/mystère-noir-et-blanc
Je suis bien d'accord. Mon point concerne GiteaPC et pas les scripts développés pour.
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.
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.
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…
Citer : Posté le 03/01/2021 00:38 | #
– 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.
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 à :
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.
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)
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.
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.
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.
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.
Mon blog ⋅ Mes autres projets
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/
Citer : Posté le 08/01/2021 11:08 | #
Ça commence à prendre forme, c'est cool
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é.
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.