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.