[DEV] Créer un installeur sur mac

**ttone** · 25/05/2008, 22h52

Bonjour, désolé si j'ouvre un topic deja créé, mais je n'ai rien trouvé a ce sujet.

En général on n'a pas besoin d installeur sue os x, mais si on fait attention certaines appli en ont un.

J'ai besoin d'en faire un pour un soft. Pour assurer la présence des libraires, notamment dynamiques, sur la machine.

Merci pour vos remarques et conseils.

**Mala** · 26/05/2008, 00h07

Il te faut utiliser l'application Package Maker dans les outils développeurs.

Un pas à pas ici...
http://www.osxgnu.org/info/osxpackages.html

**Sepia** · 26/05/2008, 01h49

Salut,

Si tu as besoin d'installateur professionnel et multi plates-formes, InstallAnyWhere de zeroG est super bien : pas trop cher, interface et paramètre similaires sur Mac, Windows, Linux (voire identiques pour pas mal de choses), très fiable. Bref bon produit (mais il reste payant même si je crois qu'il existe une version d'évaluation gratuite).

à toi de voir (en fonction de test besoins et de tes moyens).

**Ceylo** · 26/05/2008, 17h54

Les bibliothèques ne fonctionnant que pour une architecture et un OS donné, un installateur multi-plateforme...

**ttone** · 26/05/2008, 18h40

mouais ... :gratte:

**Sepia** · 28/05/2008, 00h34

Salut,

Désolé, mais l'installateur est bien multi-plateforme. Je suis un développeur Java depuis la 0.1 et si tu sais faire, tu as bien un installateur packagé (pas un package au sens java) qui fonctionne en multiplate-forme. Et avant, j'avais fait beaucoup, beaucoup de C/C++ donc il existe des mécanismes dit d'installation conditionnelle qui fonctionnent bien. Actuellement, l'installateur du logiciel que l'on développer fonctionne sur Windows 2000, Mac OS X, Lunix. Notre soft est aussi un unique jar qui marche sur les plates-formes Mac OS X, Windows NT, Windows 2000, Solaris. Nous sommes à la version v5.02 de notre soft et à quelque chose comme 2500 installations et 8 ans, jusque là pas de problème mais dès que je n'en ai un, je n'hésiterais pas à faire appel à de grands spécialistes que vous êtes surement (dans votre domaine mais qui n'est clairement pas dans la maîtrise des environnements professionnels multiplates-formes).

**ttone** · 28/05/2008, 01h02

>>Sepia

Tu dis qu'il n'est pas conditionnel ? Je n'ai jamais fais d'installeur, mais ca m'étonne, enfin bref, tant mieux!
Est ce que tu as un exemple de librairies ajoutées à l'installeur notamment qui a fonctionné en Universal ?

Pour l'instant je suis sur la version mac de mon soft, je n'ai pas un tres grand besoin d'installeur si ce n'est pour les framework (dont Qt qui semble etre récalcitrant, peut etre à cause de dylib ?) et des dylib justment...

Mais bien évidemment pour la version PC il va falloir décompacter dans Program Files j'imagine.

**Ceylo** · 28/05/2008, 14h31

Envoyé par Sepia

Désolé, mais l'installateur est bien multi-plateforme.

Ce n'est pas ça le problème. C'est plutôt se savoir si ce que tu installes est multi-plateforme. Ici il s'agit d'une bibliothèque dynamique, donc on parle d'un élément compilé, prévu pour certaines architectures et un seul OS.

P.S.: je ne connais pas trop java, ça existe les bibliothèques dynamiques à partir de ce langage ?

**ttone** · 28/05/2008, 14h49

P.S.: je ne connais pas trop java, ça existe les bibliothèques dynamiques à partir de ce langage ?

je crois bien,

les dyn lib ne sont pas compilé, si ?

**Ceylo** · 28/05/2008, 14h51

Envoyé par ttone

les dyn lib ne sont pas compilé, si ?

Si elles ne sont pas en java (je ne sais toujours pas si ça existe), si.

**ttone** · 28/05/2008, 15h24

Donc a priori pas besoin de les gérer dans l'installeur (je veus dire les redistribuer à l'installation...) ?

**Ceylo** · 28/05/2008, 19h06

Envoyé par ttone

Donc a priori pas besoin de les gérer dans l'installeur (je veus dire les redistribuer à l'installation...) ?

???
C'est peut-être la fatigue mais je ne comprends pas ce que tu veux dire.

**Sepia** · 30/05/2008, 01h32

Envoyé par ttone

je crois bien,

les dyn lib ne sont pas compilé, si ?

En effet, en Java (en dehors de certaines techniques spécifiques qui inhibent la gestion du multi-plateforme), le code est compilé mais pas en langage directement interprétable par l'OS. En fait pou être précis, on parle alors de byte-code qui est interprété lors de l'exécution par un moteur spécifique à la version de Java et la plate-forme (en Java, il s'agit de la JVM = Java Virtual Machine).

On peut donc avoir un même "executable" (en fait interprétable) Java pour plusieurs plates-formes:
Le code peut être multiplate-forme, on peut même changer l'apparence sur un PC pour être similaire (visuellement) au Mac et réciproquement. Même si cela impose des restrictions d'utilisation dans le code (du style, ne pas mettre "\" dans les noms de fichiers mais une constante comme "FILE_SEPARATOR"
Le byte code est portable : il suffit d'avoir la même JVM (et, je reconnais, ne pas tomber dans un bug de son implémentation qui marcherait sur un OS et pas sur l'autre. Mais c'est assez rare pour être considéré comme théorique)

On peut même sur un installateur indiqué quelle JVM on veut installer (soit celle du Mac, soit celle du PC) mais l'installateur reste identique, ton code aussi et ton CD d'install.

A titre d'exemple, c'est une technique similaire pour la détection des paltes-formes qui est utilisée lorsque tu veux voir un soft en démo et que tu vois apparaître un truc du type "Java Web Start" (sauf que là, il ne t'installe que la partie qui t'intéresse et que tu ne reçoit pas tout par le réseau).

**ttone** · 30/05/2008, 13h12

Donc en C++ les dyn lib ne sont pas compilé ?

Raah, ...

Il faut scripter un installeur pour chaque plateforme, afin qu'il les places au bon endroit ?

J'ai lu aussi que les dyn lib pouvait être à la racine de l'exécutable ?

En mac, on n'installe pas en général, c'est souvent un copy-paste du package dans le dossier Application, les dyn lib peuvent elles alors être incluse dans le paquet Appli.app ? (qui contient Contents/MacOS/executable)

Comment scripter ca ? Car le .app est généré à la compilation, difficie de placer les dyn lib dans une chose qui n'existe pas encore en théorie ?

Merci pour votre aide

**Ceylo** · 30/05/2008, 16h37

Envoyé par ttone

Donc en C++ les dyn lib ne sont pas compilé ?

Raah, ...

Si. Ce sont celles en java qui ne le sont pas (d'après ce que j'ai compris du post de Sepia).

Envoyé par ttone

Il faut scripter un installeur pour chaque plateforme, afin qu'il les places au bon endroit ?

Si tu restes sous Mac OS X, tu peux faire des binaires universels, comme ça tu ne te soucies plus de l'architecture.

Envoyé par ttone

J'ai lu aussi que les dyn lib pouvait être à la racine de l'exécutable ?

Oui, mais là cela dépend de l'adresse d'installation de la bibliothèque dynamique que tu donnes lorsque tu la compiles (@executable_path/libXXX.dylib par exemple).

Envoyé par ttone

En mac, on n'installe pas en général, c'est souvent un copy-paste du package dans le dossier Application, les dyn lib peuvent elles alors être incluse dans le paquet Appli.app ? (qui contient Contents/MacOS/executable)

Oui.

Envoyé par ttone

Comment scripter ca ? Car le .app est généré à la compilation, difficie de placer les dyn lib dans une chose qui n'existe pas encore en théorie ?

Ne t'en occupe pas, tu as les binaires universels (cependant limités à un seul OS).

**Sepia** · 31/05/2008, 01h04

Envoyé par Spootnik

Si. Ce sont celles en java qui ne le sont pas (d'après ce que j'ai compris du post de Sepia).

En effet.

Dans un certain sens Java peut être vu comme langage interprété par un moteur. En fait c'est la même chose (du point de vue logique) que lorsque tu fais du HTML, c'est portable (lorsque tu fais bien attention) car c'est l'interpréteur du browser de ta plate-forme qui transforme les commandes logiques en commandes système comme le fait la JVM.

Et pour en revenir à l'installateur, si lui aussi est écrit avec cette technique, lui aussi peut être portable et multi-plate-forme.

@+

**Elendhil** · 31/05/2008, 11h44

Une dylib est une librairie dynamique comme les .dll , elle est donc compilé , et utilisable uniquement sur macOSX. On peut spécifer à la compilation l'architecture du processeur ciblé : PPC ou intel ou encore les 2.

Le code se charge au lancement de l'application.

A l'édition des liens de ton programme, il va la lier en fonction du chemin correspondant à l'id de ta dylib.

Pour voir à quoi correspond le chemin , il y la commande otool -L tonAppli/ouTADylib

Si tu vois par exemple , qu'il y pas de chemin , ou que le chemin est incorrect , tu peux le redéfinir pour qu'il pointe dans le répertoire exécutable ou encore le répertoire framework relatif à ton application.

Pour faire cela j'ai cherché "un petit bout de temps" mais c'est tout con voila un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
install_name_tool -id @executable_path/libboost_date_time-1_35.dylib libboost_date_time-1_35.dylib
install_name_tool -id @executable_path/libboost_filesystem-1_35.dylib libboost_filesystem-1_35.dylib
install_name_tool -change libboost_system-1_35.dylib @executable_path/libboost_system-1_35.dylib libboost_filesystem-1_35.dylib
install_name_tool -id @executable_path/libboost_program_options-1_35.dylib libboost_program_options-1_35.dylib
install_name_tool -id @executable_path/libboost_system-1_35.dylib libboost_system-1_35.dylib
install_name_tool -id @executable_path/libboost_thread-mt-1_35.dylib libboost_thread-mt-1_35.dylib

otool -L *.dylib

Avec :
-id permet de changer le chemin de la dylib
premier argument : "le nouveau chemin" second: "la dylib à modifier"
avec:
-change permet de changer le chemin des autres dylib auquel ta dylib fait appel.
premier argument : "la dylib à changer" second : "le nouveau chemin vers lequel la trouver" et enfin le 3 : la dylib sur lequel faire ces modifications.

Pour ton application si c'est uniquement , des ressources à ajouter comme des icônes/images ect , ou des frameworks "non standard" ou encore des dylib qui ne sont pas par défaut sur tous les MacOS

Tu as juste à les ajouter dans ton .app , dans les bons répertoires :

monAppli.app/Contents/Resources correspond à toutes les ressources qu'à besoin ton appli , les icones , les images, ect.

monAppli.app/Contents/Frameworks idem mais pour les frameworks

monAppli.app/Contents/MacOS correspond à l' @executable_path

Voilà avec tout ça tu n'as pas besoin d'installeur, tu délivres juste ton .app au format zip , il le décompresse , et drop le .app avec ses autres applications .

**ttone** · 31/05/2008, 17h27

donc pour les dylib qui ne sont pas sur le systeme par défaut, le tout est de les mettre dans le paquet .app à la racine de l'exécutable ?

Sans rien spécifier d'autre a l executable ? ou alors il faut modifier l'@executable_path ?

**Elendhil** · 31/05/2008, 20h22

Oui. Mais vérifie en console avec la commande otool -L nomDelaDylib qu'il y a bien @executable_path/nomDeLaDylib d'indiqué.

Si c'est pas le cas change cela avec install_name_tool comme indiqué plus haut .