Connexion
Vous n'avez pas encore de compte personnel ? Vous devriez en créer un. Une fois enregistré vous aurez certains avantages, comme pouvoir modifier l'aspect du site, ou poster des commentaires signés...
Support
Activité du Site

Pages vues depuis 06/01/2019 : 12 711 696

  • Nb. de membres 366
  • Nb. d'articles 2 837
  • Nb. de forums 24
  • Nb. de sujets 13
  • Nb. de critiques 0

Top 10  Statistiques

Index du forum »»  Développement »» Développeur débutant sur MorphOS

Développeur débutant sur MorphOS#2209

6Contributeur(s)
BeChrisze_bucheronBeWorldPapiosaurJediTcheko
2 Modérateur(s)
PapiosaurBeWorld
BeWorld BeWorldicon_post
Le cas du package SDL2 n'est pas le plus simple à gérer, plusieurs bibliothèques inclus dans le fichier LHA.
Le package est là pour avoir un pack tout en un pour l'utilisateur final.
A mon avis, il faudrait que je découpe la SDL2, SDL2_mixer, SDL2_gfx, SDL2_net, SDL2_ttf, SDL2_image et utiliser le mode "release" de github par exemple.

Ensuite le cas du versioning des fichiers... comme 53.3 de la SDL2.library qui n'a aucun rapport avec 2.0.14 ? pq c'est comme ca....
En fait à la source, Itix c'est lui qui a créé la SDL2.library en version 53.0 basé sur la version 2.0.3, j'ai simplement continuer sur ce chemin pour garder la compatibilité...
Mais en effet comment détecter tout cela.....
Le pire c'est que je fais des mises à jour souvent du package SDL2 sans pour autant modifier la version lol.... (simplement la date change), ca risque d'être le bordel :-)

Tout cela pour dire qu'il faudra peut être s'adapter à ton futur ampkg et être plus "propre" dans le développement....







IMAC 2.1 / PB 1.5G 17 / PM G5 2.7
My Works
Papiosaur Papiosauricon_post
Je pense qu'il faut partir d'une version propre de MorphOS sinon ça va être compliqué je pense.

"On" pourrait créer un fichier dans le répertoire sys:prefs/env-archives/ nommé ampkg.prefs qui pourrait contenir ce qui a été installé sur le système.

Chaque ligne de ce fichier prefs contiendrait la liste des packets installés.

Si on veut désinstaller, ampkg désinstalle le packet et supprime la ligne correspondante dans le fichier prefs.

Pareil, pour les mise à jour, le fichier prefs contient le numéro de version et la date et ampkg le compare avec la base de données citées précédemment (faire tous les soirs à partir de morphos-storage.

voici un exemple de ligne de fichier ampkg.prefs

catégorie, lien de l'archive+nom de l'archive, numéro de version, date, chemin d'installation

Une idée comme ça en passant
 Message édité par : Papiosaur / 26-05-2021 10:47
BeChris BeChrisicon_post
Merci pour toutes ces idées.

J'ai commencé à mettre en place dans le dépôt un fichier qui contient les fonctionnalités que l'outil devra fournir : https://github.com/BeChris/ampkg/blob/master/NEEDED_FEATURES.md
Et un autre, plus technique, qui indique quels types de fichiers seront stockés et où : https://github.com/BeChris/ampkg/blob/master/FILES_FORMAT.md

C'est pas fini et ça n'est qu'en Anglais : trop la flemme de maintenir des versions en Français :)

Du coup:
@Papiosaure : on retrouve ton idée de fichier contenant la liste des paquets installés mais plutôt sous une forme de base de données SQLite (plus facile à gérer je trouve et le SQL c'est puissant et très rapide pour permettre de faire des recherches dans la liste des paquets par exemple).
Et pour la prise en charge d'un système déjà installé on peut effectivement:

  1. Exiger une installation de zéro ce qui serait le plus facile pour l'outil

  2. Ou alors indiquer que ampkg ne gère que les installations/mises à jour/désinstallations qui sont faites par lui dans un dossier spécifique (Work:Applications_ext par exemple comme tu l'as mis en place avec le pack Crysalis).


Pour la détection des fichiers contenus dans les paquets on pourrait s'en sortir par l'utilisation d'un checksum MD5 que j'ai prévu d'intégrer.
Je pencherais plutôt pour la deuxième solution et les utilisateurs pourraient ainsi garder une certaine liberté avec des logiciels non encore gérés par ampkg (le temps qu'on écrire toutes les recettes) et progressivement éventuellement basculer sur du 100% ampkg.

@BeWorld : pour cette histoire de versionnage différent, après réflexion, on s'en sort aussi avec les MD5.
En effet on peut identifier n'importe quel fichier d'un paquet non pas par la chaine "$VER" qu'il contient mais plutôt par son MD5.
Tu pourras donc rester sur ton système de version ou changer ça n'aura pas d'impact :)

Concernant le découpage en SDL2, SDL2_image, ... j'y avais effectivement pensé aussi.

Avec Papiosaure on a eu la même idée de transformer le pack Crysalis en "simple" paquet.
Dans ce paquet, tous les logiciels initialement inclus dans le gros ISO deviendront des dépendances optionelles du paquet Crysalis.
Ainsi, l'utilisateur ne sera plus forcé de tout installer : il pourra sélectionner ce qu'il veut.
Autre énorme avantage : lorsque le pack évoluera, l'utilisateur pourra se servir d'ampkg et ainsi ne télécharger que les mises à jours entre deux packs : gain de bande passante et de temps !

Si on arrive à faire un outil rapide et fiable on va tout péter !
On va faire des envieux les gars je le sens
Tcheko Tchekoicon_post
Quel est votre éditeur de code favori (qui affiche au moins numéros de lignes) ?

FlowStudio.

Rapatrier les diverses librairies pour pouvoir développer semble un petit peu laborieux : aller sur MorphOS-storage ou aminet, chercher la lib, la décompresser, ...
Il n'existe pas de système de paquets sous MorphOS avec un outil utilisable en ligne de commandes (genre pacman de ArchLinux ou le système de ports de Haiku) ?


Non. Enfin si. Grunch de Geit. http://www.geit.de/eng_grunch.html

Est-ce qu'il y a un lieu d'échange pour développeurs MorphOS (IRC, Discord, ...) ?
  • Si tu veux du soutien, IRC #morphos sur le réseau Libera.chat, les core devs de MorphOS sont généralement présents et apprécient donner de l'aide si nécessaire.

  • Morph.zone, le site officiel de MorphOS, la aussi, les core devs regardent ce qui se passent.

  • Il y a aussi un mailing list mais c'est tellement old school que même les vieux ne se rappellent plus de comment y souscrire.

  • Tu as aussi la library sur MZ. https://library.morph.zone/First_steps_in_MorphOS_programming qui donne quelques bribes d'information pour démarrer.

  • La quasi totalité de la documentation AmigaOS (<=3.1, pas OS4 avec leur Interface...) concernant la programmation est applicable (il y a toujours des angles morts ici et là mais dans l'ensemble, un bout de code C de 20 ans d'un programme Amiga devrait se compiler et fonctionner...)


Si tu veux réellement t'éclater en programmation sur MorphOS, oublie tes habitudes linuxiennes et les pratiques POSIX. L'API de MorphOS ne partage pas grand chose avec l'univers POSIX. Il y a la couche ixemul qui permet de porter des trucs d'ailleurs (ce qui permet d'avoir par exemple la suite gcc du sdk) mais c'est pas là que se trouve le fun de mon point de vue.

Si tu comptes faire du portage, BeWorld a l'habitude et pourra probablement t'aider.
Si tu comptes faire des applications 'from scratch' faisant appel à l'API native (genre une interface MUI), c'est plus 'difficile' dans le sens où il y a une bonne courbe d'apprentissage nécessaire pour y arriver. Mais bon, rien d'impossible ;)

Si c'est la seconde voie que tu envisages, je peux t'aider.