Quelles sont les recommandations pour le portage de code C ++ sur MacOS? [fermé]

Question

Pour un projet à venir, il est prévu de porter le code C ++ existant compilé sous Windows et Linux sur MacOS (leopard). Le logiciel est une application en ligne de commande, mais une interface graphique peut être planifiée. Le MacOS utilise le compilateur g ++. En ayant le même compilateur que Linux, il ne semble pas y avoir de problème, mais il y en a toujours.

Existe-t-il des recommandations ou des problèmes à surveiller pendant le port?

Answer 1

Votre application dispose-t-elle d'une interface graphique et de laquelle (native / Qt / Gtk +)?

Si ce n’est pas le cas, les problèmes à surveiller (comparés à Linux) concernent principalement le domaine des liaisons dynamiques. OS X utilise '-dylib' et '-bundle' et dispose en fait de deux types de bibliothèques dynamiques (celles qui peuvent être chargées à l'exécution et celles qui sont normales). Linux n’a qu’un seul type (-shared) et reste néanmoins plus souple.

Si votre application dispose d'une interface graphique, vous devrez tout recoder dans Cocoa à l'aide d'Objective-C. Cela signifie que vous serez également dans une nouvelle langue . Certaines personnes (comme MS) ont utilisé Carbon (API C ++), mais cette technologie est progressivement supprimée. Je ne recommanderais pas cela à de nouveaux projets.

Votre meilleure chance est d’utiliser Qt ou Gtk +. Un port Gtk + natif a été (re) annoncé il y a quelques jours (voir Imendio ).

p.s. Bien entendu, OS X exécute également des fichiers binaires X11, mais il peut s'avérer difficile de le transmettre à l'un de vos clients. Ils sont habitués à l'interface Aqua et productifs avec cela. Ne considérez X11 que comme une solution à très court terme.

p.p.s. Le nombre de bibliothèques complémentaires open source fournies avec OS X est limité, et leurs versions risquent de manquer. Tandis que sous Linux, vous pouvez facilement exiger que les utilisateurs aient installé «libxxx v.y.y», sous OS X, il existe plusieurs approches de packaging (fink, macports) et pour un outil commercial, les bibliothèques requises devraient être contenues dans l'application. OS X propose à cet effet des "ensembles d'applications" et des "cadres" (copies locales, rendant l'application autonome). Linux n'a pas un tel concept. Cela aura également un grand impact sur votre système de compilation. Peut-être voudrez-vous essayer quelque chose comme SCons pour toutes les plateformes?

Answer 2

Vous n'avez pas besoin de recoder tout en Objective-C. Il existe une étrange normalisation de C ++ et d'Objective-C qui vous permet d'utiliser le code C ++ d'Objective-C, de sorte que vous puissiez scinder intelligemment le code du modèle en C ++ et le code de vue / contrôleur en Objective-C. Pour utiliser Objective-C, il vous suffit de suffixer vos fichiers de code source avec .mm au lieu de .m, et vous pouvez mélanger la plupart des syntaxes légales C ++ et Objective-C même sur la même ligne.

Answer 3

Nous n’avons pas effectué de portage sur MacOS, mais sur divers systèmes Unix à partir de Linux. La zone de travail principale a été l’installation et les systèmes de démarrage. Attendez-vous donc à y mettre la plupart du travail portable entre Linux et Windows).

Answer 4

Macintosh (macosx) est essentiellement FreeBSD sous le capot (bien qu’il ait été modifié). Il y a quelques différences dans la programmation système entre Linux et FreeBSD. Ces différences existent principalement entre les différents appels système ... donc, l'impact sur votre application sera déterminé par le type d'appels système que vous effectuez pendant l'exécution.