Avis d'un développeur Mac...

lupus yonderboy a dit:
Quand aux optimisations altivec, elles sont plus du ressort du compilateur et des API concernées que du code en lui-même.
Non le compilateur ne fera pas le boulôt, c'est pour ta pomme. :D A toi de convertir le code altivec en code SSE, avec tous les désavantages de ce dernier.
 
Bonjour,

Je viens de faire quelque compilation en Universal Binary (un petit projet en Carbon), et j'ai remarqué un truc, j'avais oublié de sélectionné spécifiquement le SDK MacOS X 10.4 (Universal) (option "Cross-Platform Using Target SDK" des propriété du projet dans XCode), et donc il est resté sur "Current MacOS".
Or cela fait foirer le linkage (avec des jolis Undefined Symbols), il a certainement pris le SDK 10.4.0 (non Universal donc).

Conclusion, il est important de sélectionner le SDK "MacOS X 10.4 (Universal)" en plus de sélectionner l'architecture Intel pour que cela ait une chance de compiler.

A+
 
Bonjour,

ntx a dit:
Non le compilateur ne fera pas le boulôt, c'est pour ta pomme. :D A toi de convertir le code altivec en code SSE, avec tous les désavantages de ce dernier.

Il me semble pourtant qu'il existe un framework appelé "Accelerate" qui est capable de faire une interface "independante" du CPU pour les instructions Altivec (et certainement SSE3 à l'avenir (à moins que cela soit déjà géré)).

Maintenant la qualité du code obtenu c'est une autre histoire... :)

A+
 
Frodon a dit:
Il me semble pourtant qu'il existe un framework appelé "Accelerate" qui est capable de faire une interface "independante" du CPU pour les instructions Altivec (et certainement SSE3 à l'avenir (à moins que cela soit déjà géré)).
Pour les fonctions disponibles dans Accelearte, toutes concernent le traitement des images. Si tu veux faire autre chose, je crains qu'il faille développer une version altivec et une version SSE de ton code, les deux ne fonctionnant pas vraiment de la même manière et toutes les fonctionalités altivec n'ont pas d'équivalent sur SSE.
 
Didier Guillion a dit:
Si la transition est si facile pourquoi Apple n'a pas livré XCode en version x86 ?
Je me trompe certainement, mais d'apres ce que j'ai vu, ce n'est pas le cas...

Cordialement


/Developer/Applications/Xcode.app/Contents/MacOS/Xcode: Mach-O fat file with 2 architectures
/Developer/Applications/Xcode.app/Contents/MacOS/Xcode (for architecture i386): Mach-O executable i386
/Developer/Applications/Xcode.app/Contents/MacOS/Xcode (for architecture ppc): Mach-O executable ppc
 
ntx a dit:
Pour les fonctions disponibles dans Accelearte, toutes concernent le traitement des images. Si tu veux faire autre chose, je crains qu'il faille développer une version altivec et une version SSE de ton code, les deux ne fonctionnant pas vraiment de la même manière et toutes les fonctionalités altivec n'ont pas d'équivalent sur SSE.

Non, je te rassure, Accelerate est loin de ne concerner que le traitement d'images et tourne vraiment bien. Il n'y aucune raison de penser que la version Intel est/sera pourrie.

Airy
 
Pour faire un metier identique au tient mais sur des languages et des plateformes differentes je tient a te dire KNT que je comprends ton exasperation. cependant il n''oublie pas que nous somme programmeur et que ce n'est pas le probleme des utilisateurs si nous rencontrons des difficultés.
En tant que programmeur de bas niveau je pense que tu ne doit pas etre beaucoup habitué a des changements, apres tout tu discuter directementavec le proc et tu te fous (un peu) du systeme. tu controle tout. tu est maitre de ton code sans aucun intermediaire..
Tu sait avant j'etais un programmeur VB , c'etait vraiment pas la joie, et crois moi avec les dll il n'y a pas besoin de changer de procs pour etre dans la ME???E. Et sous Microsoft tu en as des changements, des incompatibilités etc..
Alors je te pose une question:
Finalement meme s'il y a un changement de proc, t'a put etre peut etre un peut plus tranquille que les autres programmeurs jusque la non ?
 
airy a dit:
Non, je te rassure, Accelerate est loin de ne concerner que le traitement d'images et tourne vraiment bien.
Exact, je ne regardais pas la bonne doc, mais seulement celle concernant l'update.
 
airy a dit:
/Developer/Applications/Xcode.app/Contents/MacOS/Xcode: Mach-O fat file with 2 architectures
/Developer/Applications/Xcode.app/Contents/MacOS/Xcode (for architecture i386): Mach-O executable i386
/Developer/Applications/Xcode.app/Contents/MacOS/Xcode (for architecture ppc): Mach-O executable ppc


A cette adresse j'ai un seul fichier de 228 Ko. Et toi ?

Cordialement
 
Frodon a dit:
Bonjour,

Je viens de faire quelque compilation en Universal Binary (un petit projet en Carbon), et j'ai remarqué un truc, j'avais oublié de sélectionné spécifiquement le SDK MacOS X 10.4 (Universal) (option "Cross-Platform Using Target SDK" des propriété du projet dans XCode), et donc il est resté sur "Current MacOS".
Or cela fait foirer le linkage (avec des jolis Undefined Symbols), il a certainement pris le SDK 10.4.0 (non Universal donc).

Conclusion, il est important de sélectionner le SDK "MacOS X 10.4 (Universal)" en plus de sélectionner l'architecture Intel pour que cela ait une chance de compiler.

A+


C'est ce que je fait, et que ce soit sur un projet Carbon ou Cocoa hyper simple, j'ai des erreurs de links.
Il y a quelque chose a installer de plus que les SDKs ?

Cordialement
 
Didier Guillion a dit:
C'est ce que je fait, et que ce soit sur un projet Carbon ou Cocoa hyper simple, j'ai des erreurs de links.
Il y a quelque chose a installer de plus que les SDKs ?

Cordialement

Perso j'ai tout installé, donc je ne sais pas ce qui joue.

A j'ai oublié de preciser un truc, visiblement quand on utilise ZeroLink (activé par défaut pour le mode Development sur les projets recents), ca ne link jamais (probablement que ca ne marche que si tu compile sur un MacIntel?). Essais en n'utilisant pas ZeroLink (à desactiver dans les propriétés du Target) et/ou de compiler en "Deployment"

Un exemple de programme que j'ai reussi à compiler en Intel (pas encore en Universal Binary):

1) Recuperer les sources de la libmad -> ftp://ftp.mars.org/pub/mpeg/libmad-0.15.0b.tar.gz
2) Télécharger les sources de StreamRipper: http://ovh.dl.sourceforge.net/sourc...0.4beta.dmg.sit
3) Compiler la precedente libmad en i386 et copier le fichier .libs/libmad.a dans le repertoire du projet de StreamRipper. Puis faire un "ranlib" dessus
4) Ouvrir le pbproject, là xcode va proposer de creer un nouveau fichier de projet upgradé, accepter
5) Selectionner le projet et afficher les propriétés de celui ci (Pomme I).
6) Dans l'onglet "General" selectionner le SDK: MacOS X 10.4 (Universal)
7) Dans l'onglet "Build" selectionner la ligne "Architecture" et cliquer sur "Edit". Puis selectionner "Intel" (et deselectionnet PowerPC)
8) Creer un nouveau Target de type Application, identique (avec les même propriétés que le precedent, mais avec l'architecture Intel. (Bien faire attention de ne pas activer ZeroLink!)
9) editer le Makefile du repertoire sripper_1x/lib et rajouter "-arch i386" aux CFLAGS;
10) Compiler StreamRipperX.

J'ai réussi à en faire un exe i386, mais pas encore un Universal Binary car il se link avec certain elements compilés separements. Cela a cependant été aisé, il a fallut juste se debrouiller pour que les elements compilés séparement (libmad.a, les elements du repertoire "sripper_1x/lib") soit compilé en i386 (-arch i386), y'a fallut aussi que je face un nouveau Target car l'ancien était à l'ancien format et compilait systematiquement en PPC.

$ file StreamRipperX
StreamRipperX: Mach-O executable i386

EDIT: J'ai reussi à faire un Universal Binary à la main avec la commande à partir des exe généré par les 2 projets PPC et i386 séparés (où ppc/StreamRipperX est l'exe PPC et i386/StreamRipperX l'exe i386):
/usr/bin/lipo -create ppc/StreamRipperX i386/StreamRipperX -output ./StreamRipperX

$ file StreamRipperX StreamRipperX: Mach-O fat file with 2 architectures
StreamRipperX (for architecture ppc): Mach-O executable ppc
StreamRipperX (for architecture i386): Mach-O executable i386

A+
 
Bonjour,

Didier Guillion a dit:
A cette adresse j'ai un seul fichier de 228 Ko. Et toi ?

Cordialement

Idem, et c'est bien compilé pour i386 et PPC:

host:/Developer/Applications/Xcode.app/Contents/MacOS frodo$ ls -l
total 456
-rwxrwxr-x 1 root admin 230132 May 28 06:33 Xcode
host:/Developer/Applications/Xcode.app/Contents/MacOS frodo$ file Xcode
Xcode: Mach-O fat file with 2 architectures
Xcode (for architecture i386): Mach-O executable i386
Xcode (for architecture ppc): Mach-O executable ppc

A+
 
Frodon a dit:
Perso j'ai tout installé, donc je ne sais pas ce qui joue.

A titre d'exemple de projet qui compile, j'ai réussi à compiler en Universal Binary le logiciel Stream Ripper.

Il faut:

1) Compiler et installer la libmad (en tapant dans le terminal: configure --prefix=/usr && make && sudo make install)-> ftp://ftp.mars.org/pub/mpeg/libmad-0.15.0b.tar.gz
2) Télécharger les sources de StreamRipper: http://ovh.dl.sourceforge.net/sourceforge/streamripperx/streamripperx-src-1.0.4beta.dmg.sit
3) Ouvrir le pbproject, là xcode va proposer de creer un nouveau fichier de projet upgradé, accepter
4) Selectionner le projet et afficher les propriétés de celui ci (Pomme I).
5) Dans l'onglet "General" selectionner le SDK: MacOS X 10.4 (Universal)
6) Dans l'onglet "Build" selectionner la ligne "Architecture" et cliquer sur "Edit". Puis selectionner "Intel" en plus de "PowerPC"
7) Fermer la fenetre des proprietés et compiler.

A+

Ok, je suis arrivé a compiler des exemples simples Carbon et Cocoa, en fait il faut faire gaffe de bien avoir choisi :
- La version 4 de GCC sinon, il ne genere pas d'erreur et ne fait que le PPC
- Desactivé les informations de ZeroLink.

Je seche toujours sur un projet AppleScript Studio et sur des projets Carbon plus complexe.

J'ai tout de meme reussit a convertir un projet d'environ 2 millions de lignes de code de CodeWarrior 8 à XCode. Il m'a fallut une trentaines d'heures tout de meme... La gestion des chemins est totalement differente sur XCode, et bon sang que c'est lent à compiler !
Environ deux fois plus lent que le CW...


Cordialement
 
Je penche vers la solution qu'Apple va entretenir un MacOS X PPC et un MacOS X Intel.
Pourquoi?
Tout simplement parce que MacOS X a eu une vie secrète de 5 ans sur Intel, je vois donc pas pourquoi cette double existence s'arrêterait. C'est une richesse incroyable d'avoir un OS ainsi compatible, il serait très étonnant qu'ils se séparent de cette capacité/compétence/indépendance.


Moi, ce qui m'inquiète, ça va être la capacité d'Apple d'amener de nouveaux développeurs à rendre leur appli compatible Mac.
Généralement, la majorité des logiciels commencent leur vie sur Windows et sont parfois proposé sur Mac. Et s'ils naissent sur Mac, très rapidement, choix économique oblige, ils vont être déclinés en version Windows. Je parle de logiciels ambitieux et à l'avenir professionnel, très certainement, mais le schéma s'applique aux jeux aussi.
Mais, là, dans quelle mesure, une boite va se mettre à investir dans un développement Mac ?

On est tous persuadé qu'on va voir apparaître une pléthore de pseudo-Virtual PC, qui permettront d'exécuter des applis Windows dans MacOS X. Et il ne s'agira plus d'émulation, mais bien d'une exécution native. Quel sera l'intérêt d'une société de proposer une solution spécifique Mac quand l'essentiel est déjà là?
MacOS X ne deviendra qu'un organiseur de fichiers.

Bien sûr, intrinséquement, MacOS X, par ses bibliothèques, etc. est bigrement plus intéressant pour un développeur, mais le marché dicte ses règles. Et là, ne Thinkant plus Different, je crains que le pouvoir de séduction ne marche plus.
 
grenoble a dit:
Bien sûr, intrinséquement, MacOS X, par ses bibliothèques, etc. est bigrement plus intéressant pour un développeur, mais le marché dicte ses règles. Et là, ne Thinkant plus Different, je crains que le pouvoir de séduction ne marche plus.
Un espoir est qu'Apple porte Cocoa sur Windows (mais alors avec un look & feel Windows bien entendu), et alors les éditeurs pourront abandonner les MFC et faire des programmes Cocoa bi-plateformes. Et là c'est tout bénef pour nous :D Mais là aussi ce n'est qu'un rêve :(
 
ntx a dit:
Un espoir est qu'Apple porte Cocoa sur Windows (mais alors avec un look & feel Windows bien entendu), et alors les éditeurs pourront abandonner les MFC et faire des programmes Cocoa bi-plateformes. Et là c'est tout bénef pour nous :D Mais là aussi ce n'est qu'un rêve :(


Oui, ce serait bien ! Ou du moins une couche de compatibilité. Quelqu'un a des informations sur le portage d'Itunes sur Windows ? A mon avis ils sont peut etre passé par la...

Cordialement
 
Bonjour, je partage à 100 % les avis de KNT et Didier Guillion. Mais outre le problème technique, il y le problème commercial. Face à un tel coup de poker que nous impose Apple, est-il encore raisonnable de développer pour MacOS? Pour les produits actuels, peut-être? (avons nous le choix? non) et encore Altivec vers son équivalent X86, cela m'inquiète :hein: . Mais pour les produits futurs, j'ai un gros doute. Pour moi Apple vient de signer l'arrêt de mort à moyen terme de MacOS, meme si jespère me tromper, d'ailleurs cela signifie aussi la fin de ma source principale de revenus (par fidélité à Apple, je n'ai jamais fait de cross-platform, à cette heure je le regrette amèrement). Persuadé qu'avec MacOS X sur Macintosh PPC nous étions tranquilles pour au moins dix ans, je pensais quitter mon boulot actuel et embaucher 2 personnes pour m'aider à concrétiser un projet personnel lourd et que j'estimais très rentable et plein d'avenir. Aujourd'hui je ne peux plus prendre le risque d'investir tout ce que je possède pour un OS dont la survie me semble compromise :( :hein: PPC est officiellement une plateforme condamnée, donc j'oublie; mais CocoaX86, cela me rappelle tellement le passé Next (je n'avais pas suivi à l'époque et j'avais bien fait vu le résultat) et me semble trop risqué, je ne vais donc rien faire, expédier les affaires courantes et attendre. Je crains pour Apple que je ne sois pas le seul. :hein:
 
Bonjour,

Klimi a dit:
Bonjour, je partage à 100 % les avis de KNT et Didier Guillion. Mais outre le problème technique, il y le problème commercial. Face à un tel coup de poker que nous impose Apple, est-il encore raisonnable de développer pour MacOS? Pour les produits actuels, peut-être? (avons nous le choix? non) et encore Altivec vers son équivalent X86, cela m'inquiète :hein: . Mais pour les produits futurs, j'ai un gros doute. Pour moi Apple vient de signer l'arrêt de mort à moyen terme de MacOS, meme si jespère me tromper, d'ailleurs cela signifie aussi la fin de ma source principale de revenus (par fidélité à Apple, je n'ai jamais fait de cross-platform, à cette heure je le regrette amèrement). Persuadé qu'avec MacOS X sur Macintosh PPC nous étions tranquilles pour au moins dix ans, je pensais quitter mon boulot actuel et embaucher 2 personnes pour m'aider à concrétiser un projet personnel lourd et que j'estimais très rentable et plein d'avenir. Aujourd'hui je ne peux plus prendre le risque d'investir tout ce que je possède pour un OS dont la survie me semble compromise :( :hein: PPC est officiellement une plateforme condamnée, donc j'oublie; mais CocoaX86, cela me rappelle tellement le passé Next (je n'avais pas suivi à l'époque et j'avais bien fait vu le résultat) et me semble trop risqué, je ne vais donc rien faire, expédier les affaires courantes et attendre. Je crains pour Apple que je ne sois pas le seul. :hein:

Si MacOS venait à mourrir un jour, ca ne serait pas dû au switch sur Intel, mais à un abandon d'a la fois les developpeurs (surement dans un premier temps) puis des clients.
Si tu as peur que MacOS meurt et donc rende ton projet subitement non viable, tu peux très bien supporter officiellement que MacOS mais faire tes logiciels suffisamment portables pour pouvoir les adapter rapidement à un autre OS au besoin.

Cela dit, fort heureusement, au vu des temoignages des grands acteurs du monde Mac, la majorité (voir la totalité) des grands acteurs adapteront leurs logiciels aux MacIntel. Et au vu des quelques reactions de developpeurs indépendant, en dehors de quelques uns, ils vont également adapter leurs logiciels. Bref, heureusement que la majorité des developpeurs ecoutent leur raison plutôt que leurs sentiments :) Donc tu n'es certainement pas le seul, mais heureusement il semble que vous soyez peu nombreux à pre-juger de l'avenir en succombant à vos sentiments.

Perso je pense que si Apple avait continué avec le PowerPC, au vu des evenements passé et au vu de la faible rapidité de l'evolution recente de ceux-ci, cela aurait rendu la plateforme peu viable à terme. Et je pense que si la plupart (idealement la totalité) des developpeurs et des utilisateurs suivent Apple sur cette transition vers le x86, ce qui est visiblement le cas, cela ne pourra alors apporter que plus de sécurité sur la viabilité de la plateforme Macintosh.
Comparé cette transition à celles de NeXT et/ou BeOS est faire une erreur, car cela n'est pas vraiment comparable. Ces plateformes était beaucoup moins répandues et encore moins supporté par les grands acteurs de l'industrie, ce qui n'est heureusement pas le cas du Mac et de MacOS X.

Perso je pense qu'Apple a pris beaucoup plus de risque avec la transition MacOS 9 -> MacOS X (bien que comme la transition sur x86 actuelle, la transition vers MacOS X était necessaire car MacOS 9 commencait serieusement à vieillir), qu'avec la presente transition sur x86 et on sait ce que cela a donné, un succès de MacOS X sans precedent, pour la première fois depuis plusieurs années, les ventes de Mac augmente de façon significative. Le x86 peut encore aider à cela, notamment pour les frileux qui ont peur qu'en passant sur Mac ils pourront pas faire tout ce qu'ils faisaient déjà (puisqu'alors ils pourront faire tourner Windows à pleine vitesse (via un logiciel du type de VMWare ou VirtualPC mais sans emulation du CPU).

Et l'argument comme quoi la possibilité de faire tourner Windows sur Mac x86 pourrait tuer MacOS X est idiot car en effet si les switchers était satisfait de leur PC/Windows, ils ne s'amuseraient pas au jour d'aujourd'hui à payer plusieurs centaines voir milliers d'euro une machine qui ne peut même plus faire tourner Windows à pleine vitesse (les Macs PPC actuels), or pourtant il y en a qui franchissent le pas. Donc il est evident que les gens qui passent du PC au Mac (ceux la même qui font augmenter les ventes de Mac à l'heure actuelle), switchent parce qu'ils veulent autre chose que Windows et donc pour MacOS X et pour certains le design des machines(comme l'a montré un temoignage d'un switcheur sur ce forum). Et c'est ce que j'ai également constaté personnellement qd je parles du Mac à des utilisateurs de PC dans mon entourage. Tous simplement AUCUNES des personnes à qui j'ai parlé du Mac n'ont été interessé par l'idée de changer type de CPU, car quoiqu'on en dise les CPU Intel (et AMD) sont des bon processeurs, et les gens n'ont pas vraiment de raison de s'en plaindre.

Je pense qu'il y a surement également eu un certain nombre de developpeurs qui ont abandonné le Mac lors de la transition 68k->PPC, surement d'ailleurs bien plus qu'il y en aura pour la transition PPC->x86, puisque la transition 68k->PPC était bien plus difficile à réaliser (et longue) puisque l'OS de l'epoque, beaucoup moins portable, s'y pretait beaucoup moins. Sans compter qu'a l'epoque Apple allait bien moins bien qu'aujourd'hui.

Bref, je ne vois aucune raison valable (i.e: basée sur la logique et la raison) d'avoir peur de cette transition. Tout montre que cela ne peut que mieux se passer que les 2 precedentes transitions (qui se sont (très) bien passées), le contexte est bien meilleur, MacOS X se prete beaucoup mieux à cette exercice et les grands acteurs du monde Mac (Adobe, Microsoft, Wolfgram, Filemaker, Blizzard, Omnigroup, Skype, Alias, Real software...etc) ont affirmé leur volonté de supporter les Macs Intel (certains d'entre eux le qualifie même de "smart move" ou encore de "very exciting" et aussi de "very good step for the Macintosh platform and [we are] confident that it will bring new users into the fold").

A+