Packager des binaires pour Mac - Page 1

Comme proposé ici: topics/117473-ti-89-mettre-un-programme
Je lance l'idée de packager nos outils Ti préférés en binaires Mac. Je suis volontaire pour faire la maintenance de ces packages, mais j'aurais besoin d'aide pour le travail initial... Je propose qu'on travaille ensemble sur ce coup.

autant te dire de suite, que si tu compte faire un truc via fink/macport & co, le resultat de ton truc sera boudé de 99.9999% des utilisateurs de mac

Je sais, je pensais plutôt inclure tout ce qu'il faut dans le .app...

Ce n'est pas a 100% possible car il faut que ça marche en CLI

cherchez comment c'est possible alors.

je trouve son initiative très intéressante.

je trouve aussi

Un lien vers le code source ?

Il n'y a pas encore de code source, c'est pour ça que c'est dans cette section; c'est un projet. Je pense que dans un premier temps, il serait assez facile d'inclure ça dans les MacPorts. Par la suite, on pourrait se pencher sur une façon de faire un peu plus évoluée...

bon, concrètement, tu as quoi pour le moment entre les mains ? ^^

une idée... et une expérience d'installation de tilp/tiemu/ktigcc sur mac... Je suis aussi en train de parcourir la documentation de xcode, pour savoir à quoi m'attendre... Comme j'ai dit, c'est un projet, et il me trotte dans la tête depuis un certain moment; je viens tout juste de me décider à le mener à bien.

ktigcc -> y'a du kde ? hmmmm, ha ouais, t'aimes le hardcore toi
y'a pas un "tigcc" sans interface (je veux dire, est-ce que tigcc a été bien pensé ?) ? ça serait peut être plus simple de se faire une interface native et d'interagir avec...

Pas faux. On peut regarder cette possibilité... En attendant, je regarde la documentation de MacPorts, afin de pouvoir réaliser la première étape (l'inclure dans les MacPorts).

Oui, ya pas besoin de l'IDE pour utiliser tigcc.

Sauf que je déconseille absolument la ligne de commande: c'est plus difficile à utiliser, et en particulier les EDIs peuvent mettre des options par défaut raisonnables pour les nouveaux projets, la ligne de commande doit proposer des choix par défaut compatibles avec les versions antiques (entre autre aucune optimisation par défaut, comme d'habitude dans GCC), donc il faut 11 switches strict minimum (-Os -ffunction-sections -fdata-sections --optimize-code --cut-ranges --reorder-sections --merge-constats --remove-unused -Wall -Wextra -Wwrite-strings) pour 99% des projets. Les EDIs mettent ces options automatiquement pour les nouveaux projets, mais la ligne de commande ne peut pas savoir que c'est un nouveau projet.

De plus, en utilisant la ligne de commande, vous perdez toute l'intégration proposée par l'EDI, par exemple l'envoi à TiEmu ou à une calculatrice en un clic, la coloration syntaxique y compris des extensions TIGCC et de l'assembleur 68k, l'autocomplétion des identifiants de TIGCCLIB etc.

Bref, la ligne de commande est dépréciée et ne sert que pour compiler les anciens projets faits avec, depuis qu'il y a KTIGCC elle ne sert plus à rien. (À noter que ni KTIGCC ni TIGCC IDE n'utilisent l'exécutable tigcc, ils appellent les composants internes directement. Chose que seuls les outils fournis avec TIGCC devraient faire, parce que ces exécutables internes peuvent changer à tout moment, par exemple le système de linking a été remplacé 3 fois dans l'histoire de TIGCC.)

Et pour revenir au sujet, à mon avis il faut absolument un système de packaging qui gère les dépendances (mais je ne sais pas ce qu'il y a dans ce domaine sous OS X), je ne comprends pas du tout cette manie des Mac-eux de tout fourrer dans l'exécutable ou paquetage, c'est totalement dingue de sortir des .app de plusieurs GO, surtout si c'est pour fournir des .app de TiLP et TiEmu avec exactement les mêmes libs dedans.

C'est tellement plus simple sous GNU/Linux, je clique sur un exécutable dans KPackageKit et il me récupère toutes les dépendances qui vont avec automatiquement, mais seulement celles qui ne sont pas déjà installés sur le système!

Kevin Kofler (./14) :
il faut absolument un système de packaging qui gère les dépendances

quelle est l'obligation ?

Kevin Kofler (./14) :
c'est totalement dingue de sortir des .app de plusieurs GO,

exemple (crédible) ?

Kevin Kofler (./14) :
surtout si c'est pour fournir des .app de TiLP et TiEmu avec exactement les mêmes libs dedans.

toi, tu n'as pas de mac, et ça se voit on peut très bien linker deux .app sur une bibliothèque partagée...

Kevin Kofler (./14) :
je ne comprends pas du tout cette manie des Mac-eux de tout fourrer dans l'exécutable

plus simple pour l'utilisateur ?

Kevin Kofler (./13) :
Chose que seuls les outils fournis avec TIGCC devraient faire, parce que ces exécutables internes peuvent changer à tout moment, par exemple le système de linking a été remplacé 3 fois dans l'histoire de TIGCC.

ouais, donc si quelqu'un veut faire un IDE, au pif pour mac, ben il ne devrait pas le faire, parce que c'est pas fourni avec tigcc ? Est-ce que les mots "spécifications" et "documentation" te disent quelque chose ?

Il y a toujours MacPorts/Fink pour ça, mais c'est en ligne de commande, et donc pas très user-friendly. L'idéal serait, je pense de faire des .pkg qui n'installent les dépendances que si elles n'y sont pas encore.

De plus, je viens de remarquer que tilp2 est dans les MacPorts... Je suis en train de l'installer.

Quand on voit le bordel pour l'installation de GTK+ pour TiEmu pour Win, on peut apprécier les packages "tout compris" en effet.
Ceci dit, je sauvegarde bien précieusement une version no-gdb qui va chercher tout seul sont GTK+ kivabien.

kim (./15) :

Kevin Kofler (./14) :
je ne comprends pas du tout cette manie des Mac-eux de tout fourrer dans l'exécutable

plus simple pour l'utilisateur ?

D'ailleurs, je ne sais pas si tu le sais, mais un .app n'est pas l'exécutable en tant que tel, mais un bundle.

Ma version W32 avec GDB installe aussi automatiquement GTK+!

Ok, j'ignorais. Je ne sais pas si c'est dur de maintenir deux packages distincts, avec et sans GDB, mais le fait de pouvoir choisir est sûrement un plus.

KillerX (./18) :
D'ailleurs, je ne sais pas si tu le sais, mais un .app n'est pas l'exécutable en tant que tel, mais un bundle.

j'ai fait joujou avec mac os, et les .app pendant 4/5 ans, donc oui je sais comment ça marche

kim (./15) :

Kevin Kofler (./14) :
il faut absolument un système de packaging qui gère les dépendances

quelle est l'obligation ?

Je l'explique juste après dans mon post.

Kevin Kofler (./14) :
c'est totalement dingue de sortir des .app de plusieurs GO,

exemple (crédible) ?

TiEmu avec toutes les dépendances (GTK+, KDE (obligatoire si tu veux l'intégration avec KTIGCC 1), Tcl/Tk) pourrait dépasser le GO. On en est à plusieurs centaines de MO en tout cas.

Kevin Kofler (./14) :
surtout si c'est pour fournir des .app de TiLP et TiEmu avec exactement les mêmes libs dedans.

toi, tu n'as pas de mac, et ça se voit on peut très bien linker deux .app sur une bibliothèque partagée...

Si elle est un framework, c'est ça? Alors fais-nous des frameworks...

Et le problème, c'est que les libs ont besoin de modifications pour en faire des frameworks.

Kevin Kofler (./14) :
je ne comprends pas du tout cette manie des Mac-eux de tout fourrer dans l'exécutable

plus simple pour l'utilisateur ?

Seulement parce que l'OS est pourri et ne gère pas les dépendances tout seul.

La meilleure solution pour l'utilisateur est la résolution automatique des dépendances comme la fait GNU/Linux.

Kevin Kofler (./13) :
Chose que seuls les outils fournis avec TIGCC devraient faire, parce que ces exécutables internes peuvent changer à tout moment, par exemple le système de linking a été remplacé 3 fois dans l'histoire de TIGCC.

ouais, donc si quelqu'un veut faire un IDE, au pif pour mac, ben il ne devrait pas le faire, parce que c'est pas fourni avec tigcc ? Est-ce que les mots "spécifications" et "documentation" te disent quelque chose ?

Si c'est un EDI qui le fait, au moins il y a des chances de mettre à jour l'EDI si TIGCC change, sans casser la compatibilité des projets. Mais il est mieux de passer par l'exécutable tigcc même dans les EDIs non-officiels.

Ce que je ne veux surtout pas voir, ce sont des appels directement à gcc/as/ld-tigcc dans les makefiles des projets individuels, ça n'a rien à faire là-dedans, il faut passer par l'exécutable tigcc qui est l'interface spécifiée/documentée justement.

kim > je m'adressais surtout à Kevin, et comme tu l'avais déjà cité, j'avais la flemme de remonter chercher son post...

kevin > ok, on peut regarder pour ça...

Kevin Kofler (./22) :
Je l'explique juste après dans mon post.

donc en gros, celui qui a ton "installeur" ne peut rien installer s'il n'a pas internet, sauf à savoir à l'avance ce qu'il doit installer et donc faire le téléchargement lui même, j'ai bon ? C'est un exemple simple, bête, mais on peut en trouver bien d'autres dans le genre je pense. D'autant que ce que tu fais avec tigcc sous windows (qui va chercher et installer gtk), n'a aucune raison d'être infaisable sous mac os.

Kevin Kofler (./22) :
TiEmu avec toutes les dépendances (GTK+, KDE (obligatoire si tu veux l'intégration avec KTIGCC 1), Tcl/Tk) pourrait dépasser le GO. On en est à plusieurs centaines de MO en tout cas.

Pour donner une idée, je ne considère pas The Gimp comme un exemple crédible. Si tu fais des dépendances à KDE, il est *normal* de devoir installer à un moment ou à un autre KDE. Pareil pour GTK.
Le problème, c'est la trop forte dépendance à des bibliothèques non natives.

Kevin Kofler (./22) :
Seulement parce que l'OS est pourri et ne gère pas les dépendances tout seul.

Faux, il gère les dépendance comme tout Unix *aussi*, j'aurais tendance à dire qu'à ce niveau là, il est mieux placé qu'un linux lambda d'ailleurs, parce que justement il propose les deux solutions, et de manière simple pour la solution "package in"

Kevin Kofler (./22) :
Si c'est un EDI qui le fait, au moins il y a des chances de mettre à jour l'EDI si TIGCC change, sans casser la compatibilité des projets. Mais il est mieux de passer par l'exécutable tigcc même dans les EDIs non-officiels.

tu n'as pas compris ma question, mais c'est pas grave

Kevin Kofler (./22) :
Si elle est un framework, c'est ça? Alors fais-nous des frameworks...

pas forcément, il se trouve qu'on peut tout à fait faire un pkg qui installe des libs systèmes sans framework ni rien. Exemple con qui me vient à l'esprit, même si c'est pas forcément le meilleur : X11.

kim (./24) :
donc en gros, celui qui a ton "installeur" ne peut rien installer s'il n'a pas internet

On n'est plus au 20ème siècle.

Et ton dmg, il arrive sur la machine par magie? Par téléportation? Par télépathie?

D'autant que ce que tu fais avec tigcc sous windows (qui va chercher et installer gtk), n'a aucune raison d'être infaisable sous mac os.

Ben, c'est une résolution automatique des dépendances, sous-optimale parce que c'est l'installeur qui doit faire tout le boulot alors que ça devrait être le système d'exploitation, mais c'est une solution. (Mais encore faut-il une convention standard pour les runtimes GTK+ comme c'est le cas sous W32, sinon ça ne sera pas partagé correctement entre logiciels d'auteurs/packageurs différents!)

Le problème, c'est la trop forte dépendance à des bibliothèques non natives.

Un logiciel portable utilise des bibliothèques portables, évidemment. Le problème est que OS X ne propose d'office en grande partie que des libs propriétaires et monoplateformes, évidemment ces libs ne sont pas exploitables dans les applications multiplateformes.

Faux, il gère les dépendance comme tout Unix *aussi*, j'aurais tendance à dire qu'à ce niveau là, il est mieux placé qu'un linux lambda d'ailleurs, parce que justement il propose les deux solutions, et de manière simple pour la solution "package in"

Ah bon? Alors dis-moi comment faire des binaires de KTIGCC qui s'installent avec un simple yum install ktigcc ou apt-get install ktigcc sans rien installer d'autre avant (sauf éventuellement une configuration de dépôt), tout en utilisant des libs partagées, téléchargées et installées une seule fois même si on utilise KTIGCC, TiEmu et TiLP...

Le mieux dont je suis au courant, c'est Fink, mais c'est à installer d'abord, et la dernière fois que j'ai vérifié (ça a peut-être changé depuis), les binaires fournis des bibliothèques n'étaient pas du tout à jour et n'étaient pas suffisantes pour TiEmu et KTIGCC, donc il faudrait d'abord packager les bibliothèques à jour et fournir un dépôt apt avec tout ça.

Kevin Kofler (./22) :
Si c'est un EDI qui le fait, au moins il y a des chances de mettre à jour l'EDI si TIGCC change, sans casser la compatibilité des projets. Mais il est mieux de passer par l'exécutable tigcc même dans les EDIs non-officiels.

tu n'as pas compris ma question, mais c'est pas grave

J'ai plutôt l'impression que tu n'as pas compris ma réponse, ou le message d'origine.

Je n'ai pas dit qu'il ne fallait pas faire d'EDI tiers (même si c'est probablement une mauvaise idée, sauf si vous voulez partir de zéro et imiter l'interface, les fonctionnalités et le comportement de TIGCC IDE comme je l'ai fait dans KTIGCC), j'ai juste dit que les EDIs tiers et surtout les makefiles des projets individuels sont censés appeler tigcc, pas gcc, as ou ld-tigcc directement.

"Nan mais les gars, faut utiliser les fonctions de windows.h pour vos menus de jeux en gris, c'est built-in et ça respecte le look&feel natif de la plateforme voyons" ~(c).

C'est pas pareil sur PC/Mac ?

"On n'est plus au XXème siècle"...

Je me souviens encore de tes tirades sur Windows ME

Kevin Kofler (./25) :
On n'est plus au 20ème siècle.

Non, et pourtant. Et pourtant, si je voulais, je ne pourrais pas installer ton appli au taff : je n'ai pas internet. je devrais donc prendre une clé usb, récupérer l'archive, et voir que... Ha ben il manque quelque chose. Qui n'est d'ailleurs pas hébergé sur le même serveur que le tien, si ? Et qu'est-ce qu'il se passe si, ho, juste comme ça, le serveur de l'appli manquante, tombe en rade, ou simplement, n'existe plus ?

Kevin Kofler (./25) :
Un logiciel portable utilise des bibliothèques portables, évidemment. Le problème est que OS X ne propose d'office en grande partie que des libs propriétaires et monoplateformes, évidemment ces libs ne sont pas exploitables dans les applications multiplateformes.

Il te manque quoi concrètement ? C'est marrant comme toute discussion avec toi semble toujours tourner à une confrontation là où on ne te demande pas de chercher à comprendre, mais de simplifier les choses quand c'est possible... Il te manque quoi sous osx, que tu as sous windows par exemple ? Si tu voulais du vrai multiplateforme, tu aurais utilisé java, ou le moteur derrière firefox (dont le nom m'échappe, faut pas m'en vouloir, il est tard). Par exemple. Ou .net, tiens... Il se trouve que pour pas mal d'éléments d'osx, il existe des alternatives.... Qui tourne même sous linux, par exemple

Kevin Kofler (./25) :
Le mieux dont je suis au courant, c'est Fink, mais c'est à installer d'abord, et la dernière fois que j'ai vérifié (ça a peut-être changé depuis), les binaires fournis des bibliothèques n'étaient pas du tout à jour et n'étaient pas suffisantes pour TiEmu et KTIGCC, donc il faudrait d'abord packager les bibliothèques à jour et fournir un dépôt apt avec tout ça.

Kevin Kofler (./25) :
Ah bon? Alors dis-moi comment faire des binaires de KTIGCC qui s'installent avec un simple yum install ktigcc ou apt-get install ktigcc sans rien installer d'autre avant (sauf éventuellement une configuration de dépôt), tout en utilisant des libs partagées, téléchargées et installées une seule fois même si on utilise KTIGCC, TiEmu et TiLP...

C'est le rôle du packageur de fournir la solution. Si je te dis qu'une solution est possible avec un simple pkg, c'est qu'il y en a. X11 par exemple, va t'installer, ô surprise, des .so dans /usr/lib (de mémoire, pour le répertoire), de la conf dans /etc/X11..., fou non ? Et il se trouve même que OpenOffice.org en version 2 était même capable de la même "prouesse" à une époque. Il savait quand X11 était là ou pas, donc il bloquait l'installation. Au premier lancement, il allait chercher sagement les fonts systèmes dont il avait besoin, etc. Rien n'est impossible, c'est le boulot du dev & du packageur de fournir une solution.
Il existe même des systèmes de packages qui gèrent les dépendances etc.
Tiens, un truc qui peut t'intéresser (ou pas), vu que tu ne connais pas *du tout* le monde mac : cherche i-installer par exemple...

Kevin Kofler (./25) :
Je n'ai pas dit qu'il ne fallait pas faire d'EDI tiers (même si c'est probablement une mauvaise idée, sauf si vous voulez partir de zéro et imiter l'interface, les fonctionnalités et le comportement de TIGCC IDE comme je l'ai fait dans KTIGCC), j'ai juste dit que les EDIs tiers et surtout les makefiles des projets individuels sont censés appeler tigcc, pas gcc, as ou ld-tigcc directement.

que dire. Un logiciel ne pourra jamais être aussi bon qu'avec des libs natives. Ca vaut pour macos, tout autant que pour linux (firefox sur kde, c'est un peu un contre sens d'une certaine manière, par exemple), et sous windows (gtk/kde sous windows). Et si l'application est pensée pour le multiplateforme dès le départ, changer de toolkit (de gtk à kde à autre) devrait être un jeu d'enfant.
Note qu'il me semble qu'on n'a *jamais* parlé des makefiles des projets individuels... On n'a jamais causé d'utilisateurs qui vont aller jouer avec as dans leur makefile.
Juste que tu déconseilles une personne voulant faire un IDE par dessus tigcc, d'utiliser les mêmes méthodes que ktigcc par exemple, c'est à dire, passer par gcc, as, ld-tigcc etc. Et je trouve que cet avis est pour moi une erreur. Il n'y a aucune raison pour qu'un tel IDE n'ait pas à le faire, si les specs/docs sont là, et sont claires, maintenues..., alors à chaque changement, il suffit de reporter les modifs qui vont bien. Encore une fois, c'est le rôle du mainteneur...

Tu sais, Gimp, sous mac, n'a jamais percé, pour plusieurs raisons :
* il lui faut X11. (ca a été longtemps un frein pour OpenOffice.org), meme si ça s'installe avec le dvd fourni avec l'os...
* il lui faut gtk, qui n'est pas natif, et qui ne s'integre pas à mac os.
* il est long à charger, parce qu'il n'utilise pas du natif (pareil pour OOo)
* les packageurs de gimp n'ont je crois jamais compris que créer un framework, ou simplement, faire un pkg qui installe un bout en sys, et le reste sur l'app, leur permettait de proposer des package standalone en meme temps que des packages d'upgrade...

Folco (./26) :
C'est pas pareil sur PC/Mac ?

pour cette question, oui, gtk s'integre pas du tout au look&feel mac sous mac (pareil pour KDE)

En attendant, MacPorts fonctionne assez bien, je viens d'installer un tilp qui fonctionne.. Je vais m'attaquer à tiemu maintenant.