Version imprimable
Pour ceux que cela intéresse je travaille sous mac et j'utilise XCode 2.1 du moins je suis en train de le tester comme outil.
Voici un lien vers leurs docs.Si vous avez des liens vers des tutos simpas qui expliquent l'utilisation de XCode je suis prenant (en français :p) en anglais aussi bien sûr cela va de soit.
http://developer.apple.com/documenta...code-date.html
XCode, menu "help" puis "XCode Help". Cela détail assez bien l'ensemble de l'éditeur. Cela ne te convient pas?
Merci pour ce lien.
;)
A noter que le lien de zaphibel pointe vers la documentation Apple. Celle-ci est aussi installée en local sur la machine avec les dev tools (le menu dans Xcode pointe d'ailleurs dessus):
/Developer/ADC Reference Library/index.html
Il suffit d'aller dans "Tools" pour retrouver la doc spécifique à Xcode.
Pour peu de s'inscrire gratuitement, à l'offre ADC de base. Voir ici...
Devenez membre de l’ADC
...on peut télécharger non seulement les dernières mises à jour des dev tools mais aussi les nouvelles version de la doc.
Cela peut s'avérer pratique de se tenir à jour si on se retrouve en nomade avec un portable et sans connexion web. ;)
Effectivement.
Je suis déjà membre . ;)
Je n'en attendais pas moins de ta part! :DCitation:
Envoyé par kOrt3x
Zaphibel, que fais tu exactement sous Xcode ou plutôt quel langage? Java, C, C++, Obj-C? Il existe des multitudes de tutoriels sur Xcode mais généralement ils sont très ciblés Objective-C/Cocoa.
Il y a par exemple pas mal de tutoriels sympa en Français sur Project Omega.
Voir ici..
Tutoriels Project Omega
C'est vrai qu'il est vraiment intéressant ce site. ;)
J'ai developpé une application en C++ qui se base sur du multithreading.
Je l'ai développé sur windows. Mes supérieurs veulent que je la porte sur Mac et Linux. Le problème c'est que je m'y connais pas trop en XCode.
Je vais plutôt me rabbatre sur du Makefile. XCode est très complexe. Il me génère plein de fichiers 8O et ça me dépasse. Bon je connais la bête que depuis 5h. Donc je vais voir. En cas je vous demanderez des Infos.
En fait j'ai une question j'ai compilé un framework et ça m'a généré des .dylib
est ce normal que je n'ai que des .so en forme de lien et à quoi sert ces dylib?
Merci et bon code
C'est très (trop) vague pour pouvoir vraiment t'aider. ;) Le portage d'une application est quelque chose de complexe qui demande du recul. C'est d'autant plus vrai que le multithreading est souvent très lié à l'architecture du système.Citation:
Envoyé par zaphibel
Avant d'envisager un portage, il faut déjà se poser les bonnes questions:Citation:
Envoyé par zaphibel
- Quel environnement de dev a été utilisé sur PC? Visual, C++ Builder, gcc?
- L'application comporte-t-elle des interfaces graphiques?
- Le code a-t-il seulement été codé dans un esprit de portabilité (pas d'utilisation de librairies C++ spécifiques à Windows)?
- Sur Mac l'application doit-elle être Universal Binary (compatible PPC/Intel)? Si oui cela peut impliquer des swap mémoire si des données binaires sont manipulées.
Pour faire simple: dylib -> librairie dynamique -> équivalent des DLL sous Windows.Citation:
Envoyé par zaphibel
Voir wikipedia pour la culture génrérale...
Voilà j'ai développé sous Visual et j'ai utilisé un framework qui s'appelle ACE (adaptive communication enviroment) qui assure le portage en multi OS. La différence avec visual c'est que je me retrouve à compiler ACE sous Mac OSX 10.4.4 et j'ai des erreurs à la fin de la compilation pendant la phase de tests.
(Ne vous inquitètez pas j'ai buildé ACE avec windows mais j'ai moins d'erreurs :evilred: ). Contrairement à Windows qui utilse les dll et à linux qui utilise des so je vois qu'il génère des dylib.
Je ne sais pas mais on m'a dit que otool permettait de voir les parties d'un dylib le problème c'est que c'est un outil; Je ne peux pas porter de jugement parceque je ne sais pas de quoi est formée un dylib.
Enfin je vais me rabbatre sur un makefile. Pour compiler mon appli. Pour faire les dépendances des objets (y a des includes de tous les cotés :aie: )
Bon voilà.
D'accord, je comprends un peu mieux.
De mémoire, les .dylib sont identiques à des .so à l'extension près. Cela semble d'ailleurs confirmé par le lien que je t'ai donné plus haut:
Je ne connais pas ACE pour trop m'avancer mais en toute logique, d'après ce que tu disais à propos des liens symboliques, il y a fort a parier pour qu'en fait ce soit de simples redirections vers les dylib afin de garantir la compatibilité de nommage (unification des makefiles?).Citation:
Mac OS X and upwards
...can use .so-style dynamically-linked libraries (with the .dylib suffix instead)...
Si tu as codé ton projet sous visual, je suppose que tu travailles avec des projets dsp? Donc point de salut niveau portabilité de compilation. Si tu as utilisé les makefiles à la sauce Visual (nmake), ils ne sont, me semble-t-il, de toute façon pas standards donc cela ne change pas le problème. Du coup effectivement, du tout makefile pour la version Mac et Linux serait un moindre mal pour faciliter la maintenance par la suite.