Packager des binaires pour Mac - Page 4

Bon, pour revenir au sujet, ce que je verrais bien comme binaires, ce serait un dépôt de paquetages binaires, un peu comme http://repo.calcforge.org/fedora/ ou http://repo.calcforge.org/debian/, et un installeur qui configure ce dépôt et ensuite permet d'installer facilement KTIGCC, TiEmu et/ou TiLP (et leurs dépendances évidemment) à partir de ce dépôt.

C'est en fait pour ça que je demande l'avis des experts de OS X: vous verriez quoi comme solution pour ça?

Celles dont je suis au courant:
* http://www.finkproject.org/ - dpkg et apt, il est sans doûte possible de faire un dépôt tiers avec tout ce qui n'est pas dans le dépôt Fink,
* le fork RPM5 de RPM est disponible pour OS X et il y a un dépôt de paquetages.
Dans les 2 cas, la partie "installeur graphique" resterait probablement à développer. Mais déjà "installez Fink et la configuration de dépôt à [URL] et lancez fink install ktigcc", même si ça reste lourd, serait déjà mieux comme instructions que de devoir tout compiler! Mais si vous avez mieux à proposer (dans cette même direction, même si vous la détestez!), ça m'intéresse. (J'espère que KillerX nous écoute encore après tout le hors-sujet...)

bah si tu pars sur une solution type paquetages binaires à la linux, alors je pense qu'il vaut mieux passer par fink, qui est plus populaire et répandu. fink a un installeur graphique soit dit en passant, qui s'installe dans Applications. par contre après faut faire ajouter son dépot à ceux de fink.

La question est faut il vraiment un dépot?
Ca a certes ces avantages, mais ça va a l'encontre des habitudes des utilisateur mac. Le public visé n'étant pas forcément très technique, il vaut mieux ce conformer aux usages mac et fournir des pacquage installables classiques.

Ouais, je suis de cet avis... Mais dans un premier temps, il faudrait faire ajouter tilp, tiemu et ktigcc à ces systèmes de gestion de paquets...

kim (./92) :
par contre après faut faire ajouter son dépot à ceux de fink.

Et ensuite aussi proposer une interface graphique pour installer ses logiciels? Ou alors proposent-ils Synaptic ou quelque chose du genre chez Fink?

Kevin Kofler (./91) :
Bon, pour revenir au sujet, ce que je verrais bien comme binaires, ce serait un dépôt de paquetages binaires, un peu comme http://repo.calcforge.org/fedora/ ou http://repo.calcforge.org/debian/, et un installeur qui configure ce dépôt et ensuite permet d'installer facilement KTIGCC, TiEmu et/ou TiLP (et leurs dépendances évidemment) à partir de ce dépôt.

C'est en fait pour ça que je demande l'avis des experts de OS X: vous verriez quoi comme solution pour ça?

Honnêtement ? Poubelle direct... rien ne vaut un bon .app, sans rien à faire pour l'installer

Kevin Kofler (./95) :
Et ensuite aussi proposer une interface graphique pour installer ses logiciels? Ou alors proposent-ils Synaptic ou quelque chose du genre chez Fink?

ils ont déjà.

./93 :

Je suis bien d'accord qu'il faut soit un .pkg ou un .app. Cependant, la solution la plus facile dans l'immédiat serait de faire comme dit Kevin, étant donné que ce n'est pas déjà fait, ou alors, seulement en partie. Je sais que tilp est disponible sur MacPorts, et que tiemu l'est dans Fink. Ce serait bien d'en adopter un seul des deux, par souci d'uniformité, ou alors le faire pour les deux. Par la suite, on pourrait rendre ktigcc disponible lui aussi. Ce serait une bonne première étape, je trouve. Les Mac users du monde TI n'auraient plus qu'à taper une commande au terminal, et tout se ferait automatiquement. Bien sûr, ce n'est pas la façon Mac, mais c'est un bon point de départ, et c'est certainement mieux que d'avoir à tout compiler soi-même comme je l'ai fait...

Il faudrait aussi compiler au moins TiEmu avec le support KDE (3) activé, sinon KTIGCC 1 ne peut pas communiquer avec (ça se passe par DCOP qui fait partie de KDE 3). (Pour KTIGCC 2, c'est le support D-Bus qu'il faudra activer. Mais KTIGCC 2 n'est pas encore prêt à l'usage, je déconseille fortement de le packager en l'état pré-alpha actuel. On peut aussi activer les 2 (KDE et D-Bus) en même temps dans TiEmu.) TiLP et GFM peuvent être compilés sans le support KDE sous OS X.

Bon, allez... MacPorts ou Fink en premier?

À mon avis, un dépôt binaire à utiliser avec Fink. S'il faut compiler, ça va déjà chasser pas mal d'utilisateurs.

À mon avis, un dépôt binaire à utiliser avec Fink. S'il faut compiler, ça va déjà chasser pas mal d'utilisateurs (même si c'est automatique, parce que ça prend un temps fou).

Uther (./93) :
La question est faut il vraiment un dépot?
Ca a certes ces avantages, mais ça va a l'encontre des habitudes des utilisateur mac. Le public visé n'étant pas forcément très technique, il vaut mieux ce conformer aux usages mac et fournir des pacquage installables classiques.

Sans compter que les utilisateurs de fink ne vont pas l'utiliser s'ils ont déjà MacPorts, et réciproquement..

il va falloir installer la moitiée de la base de KDE3 ? pour pouvoir faire un simple "dialogue" entre TIEmu et l'autre truc ?^42

Je me pose une question peut-être bête vu que je ne me suis jamais penché sur le sujet, mais est-ce qu'il ne serait pas plus simple et plus portable de faire communiquer 2 application par réseau via 127.0.0.1.
C'est quelque chose de très simple, léger et dispo sous toute les plateformes, il ma semble. Non?

De toute façon DCOP, c'est temporaire (pour KTIGCC 1 seulement) et ça ne va pas changer dans KTIGCC 1. KTIGCC 2 utilisera D-Bus, donc TiEmu ne doit être compilé qu'avec D-Bus (il faut dbus et dbus-glib), pas KDE. À la limite, je pourrais backporter le code D-Bus de KTIGCC 2 vers KTIGCC 1 (ou une branche ktigcc-1-dbus-branch) à l'aide du binding Qt 3 (le "dbus-qt-qt3-backport", qui propose à peu près la même interface que sous Qt 4), mais je pense que compléter KTIGCC 2 est probablement plus important à long terme (mais si quelqu'un a envie de faire le backport D-Bus, allez-y, à mon avis ça ne devrait pas être trop dur).

Pour moi, D-Bus est la bonne solution à long terme, c'est multiplateforme, il y a des bindings pour Qt/KDE et GLib/GObject (c'est le mécanisme d'IPC préféré de KDE 4 et de GNOME) et c'est le bon niveau d'abstraction. Utiliser les sockets directement donnerait un bordel absolument non maintenable.

"ils" disent que ça lagge, c'est pour ça qu'il y a les sockets du domaine unix par exemple

D-Bus est effectivement une bonne solution à long terme, mais actuellement, il ne fonctionne pas sur "juste" ~90% du marché des ordinateurs. Source http://www.freedesktop.org/wiki/Software/dbus , "a port to Windows is in progress".

http://windbus.sourceforge.net/
Ça marche très bien, le projet kdewin l'utilise. (D-Bus est une dépendance obligatoire de KDE 4.)

Alors la page de D-Bus n'est pas à jour et devrait être corrigée

Ça marche très bien

Je te crois, mais

le projet kdewin l'utilise

n'est pas un gage de "ça marche très bien"

Le projet D-Bus n'aime pas la qualité des patches de windbus, c'est pour ça qu'officiellement "ce n'est pas disponible".