[Tutorial] Installer TILP sur Mac OS X

My calculator programs · by **Adriweb** » 09 Jan 2017, 11:49

Il le fait, mais...
"configure: WARNING: unrecognized options: --enable-iconv"

Faut enlever des anciens trucs obsolètes ?

→ **MyCalcs** profile · by **Lionel Debroux** » 09 Jan 2017, 12:06

Ah oui. Donc il faudrait linker avec libiconv sous MacOS X également ?

My calculator programs · by **Adriweb** » 09 Jan 2017, 12:42

Ce serait étrange, il ne me semble pas avoir eu besoin de faire des choses spéciales relatives à libiconv, de mon côté... Je regarderai en détail ce soir

J'en profiterai probablement pour faire un .app "wrapper" du binaire avec toutes les .dylib dedans, je le mettrai en archives.

→ **MyCalcs** profile · by **louis abraham** » 09 Jan 2017, 13:17

Ce serait tellement bien une .app

→ **MyCalcs** profile · by **Lionel Debroux** » 09 Jan 2017, 15:25

Adriweb a clairement pas mal de projets plus prioritaires qu'une app MacOS X (ou au moins un DMG) pour TILP

Techniquement, les outils existent pour faire des builds automatiques pour les trois principaux OS:
* en plus de certaines distros Linux, Travis CI gère les builds MacOS X, donc on pourrait avoir des builds automatiques des libti* sous MacOS X à frais limités, puisqu'il y a déjà des builds Linux (actuellement Ubuntu Trusty; pas de packaging)
* pour Windows, il y a AppVeyor, non utilisé par libti*.
Des builds complets de packages pour Windows, MacOS X et les principales distros Linux sont beaucoup plus de boulot. Déjà, il faudrait commencer par automatiser les builds de la partie graphique pour Travis CI et AppVeyor... mais c'est un boulot conséquent sur les OS qui ne disposent pas d'un bon système de packaging pour GTK+ et tout le bazar associé, en particulier Windows (MacOS X, grâce à brew, est nettement moins affecté).

Une réécriture en Qt de l'interface graphique est un vieil élément de wish list, qui aurait nombre de bénéfices, y compris pour l'intégration continue... mais qui a les moyens de faire ce travail ? Si TILP avait des dizaines de milliers d'utilisateurs, ça pourrait peut-être se justifier - mais TILP n'a pas une telle popularité, loin s'en faut.

My calculator programs · by **Adriweb** » 09 Jan 2017, 18:33

En effet, j'ai pas mal de choses sur mames todo-lists, mais je vais essayer de prendre un peu de temps ce soir pour voir ce que je peux faire.
Bien sûr, comme dit, le bon/seul plan à long terme et du déploiement continu comme l'a expliqué Lionel - c'est pas les outils qui manquent, mais le temps pour s'y coller, malheureusement.

My calculator programs · by **Adriweb** » 09 Jan 2017, 19:20

Je ne promets rien, mais avec plusieurs outils qui ont grandement facilité/automatisé la tâche, ça donne ceci pour TiLP2 1.18:
Merci de tester, j'ai aucune idée si ça marche sur une machine n'ayant pas déjà les dépendances d'installées...

Ya quelques libs dedans : https://i.imgur.com/mhMzRiM.png ^^

→ **MyCalcs** profile · by **louis abraham** » 09 Jan 2017, 20:00

"tilp a quitté de manière imprévue."
Merci d'avoir essayé

My calculator programs · by **Adriweb** » 09 Jan 2017, 20:03

Ben c'était à prévoir, mais il faudrait surtout savoir ce que ça raconte dans la console.

Dans un Terminal, lance ça: /Applications/tilp.app/Contents/MacOS/tilp (en supposant que tu aies déplacé/copié l'appli dans le dossier Applications)

Edit:
En regardant avec dtruss ce qu'il se passait, j'ai vu quelques références "hardcodées" a des trucs que brew fait.
Je me demande si ça marcherait si d'abord les dépendances sont installées (les 5 premières étapes d'ici), puis que l'appli soit lancée ?

My calculator programs · by **Adriweb** » 23 Dec 2018, 15:24

Ces derniers jours, je me suis efforcé de faire ce qu'il faut pour pouvoir avoir un systeme de build basé sur CMake, pour libti* et tilp+gfm.
Au coût de laisser de côté (à priori) la compatibilité avec des systèmes étranges/archaïques (parce que je n'ai simplement pas pris le temps de m'en occuper, mais ce serait faisable...)
On gagne beaucoup en clarté sur le système de build (ca remplace autotools etc.), sa maintenabilité, le temps de build... Du moins c'est mon avis, mais le nombre de lignes est une mesure objective

Par ailleurs, ça a l'effet de bord positif de rendre plutôt trivial le link static (c'était de toute façon assez trivial avant aussi), surtout pour libti*, mais aussi pour tilp et gfm.
Sauf pour gfm_static qui a des erreurs au runtime, tout fonctionne, so far (libti* shared+static, tilp stared+static, gfm shared)

En gros, je vais donc tenter de faire une build de tilp "autant static que possible" pour simplifier la distribution de tilp

Si ça fonctionne comme je l'espère, il n'y aura plus que quelques composants à installer via brew (car malheureusement, certains trucs gui comme gtk ne sont pas fournis en static facilement). Dans tous les cas, le but est de ne plus avoir de compilation à faire par soi-même, ce qui met une certaine barriere, au final, à un certain nombre d'utilisateurs.

La derniere fois que j'ai tenté de packager les dylibs dans le .app directement, ça n'a pas fonctionné, malheureusement, donc il faudrait essayer de creuser, si jamais, ca permettrait de ne plus avoir directement qu'un fichier à distribuer... mais bon on progresse déjà par ailleurs.

(side-effect supplémentaire de tout ceci : ça permet d'avancer un peu sur un éventuel WebTILP via webassembly, qui a besoin de link static)

Cf. https://github.com/adriweb/tilp_and_gfm/tree/cmake et https://github.com/adriweb/tilibs/tree/cmake
Ce n'est pas encore tout à fait prêt pour être mergé, mais ce n'est pas super loin non plus je pense.