Didier Guillion a dit:
la compilation distribuée sur plusieurs XServe et stations G5...Ca c'est pro
Codewarrior 10 - La version ultime.
- Créateur du sujet Didier Guillion
- Date de début
la compilation distribuée sur plusieurs XServe et stations G5...Ca c'est pro
cretinoïde a dit:la compilation distribuée sur plusieurs XServe et stations G5...Ca c'est pro
Je crois que tu t'es un peu trompé de planete...
Cordialement
Je suis de l'avis de Didier sur le temps de compilation.
Codewarrior possède un compilateur intégré très rapide. Je ne pense pas que le compilateur de codewarrior puisse s'utiliser avec XCode.
J'ai eu à développer un gros projet en Cocoa, avec de la vidéo, du réseau, et pas mal d'interface graphique, et les temps de compilation étaient parfois assez long.
Sous CodeWarrior, on allait à l'époque 5 fois plus vite qu'avec gcc et XCode!!!
Maintenant, il parait que le retard est un peu ratrapé grâce aux "precompiled headers" (C'est ça Didier?), mais il est quand même toujours en retrait au niveau du temps de compil.
Bon, là, c'était pour comparer gcc et le compilo de Codewarrior. Remarque que si tu uilises XLC, je ne pense pas que tu gagnes non plus en temps de compilation, sans compter, il me semble, qu'il ne compile pas de code ObjectiveC.
Pour info, Cocoa marche très bien avec Codewarrior. je ne vois pas pourquoi Core Data et Core Image ne fonctionnerait pas avec CodeWarrior également. Pour les bindings, je ne sais pas s'il fonctionnent avec CodeWarrior, mais Didier pourra certainement répondre sur ce point.
Pour ma part, j'avoue préférer XCode, mais c'est surtout parce que j'avais trouvé CodeWarrior assez compliqué. Par contre, le temps de compilation est très important et il est indéniable que CodeWarrior va plus vite.
J'attends également les liens vers de grosses appli développées avec XCode. Ce n'est pas que je doute qu'il y en ait, mais il faut bien prouver ses arguments.
Codewarrior possède un compilateur intégré très rapide. Je ne pense pas que le compilateur de codewarrior puisse s'utiliser avec XCode.
J'ai eu à développer un gros projet en Cocoa, avec de la vidéo, du réseau, et pas mal d'interface graphique, et les temps de compilation étaient parfois assez long.
Sous CodeWarrior, on allait à l'époque 5 fois plus vite qu'avec gcc et XCode!!!
Maintenant, il parait que le retard est un peu ratrapé grâce aux "precompiled headers" (C'est ça Didier?), mais il est quand même toujours en retrait au niveau du temps de compil.
Bon, là, c'était pour comparer gcc et le compilo de Codewarrior. Remarque que si tu uilises XLC, je ne pense pas que tu gagnes non plus en temps de compilation, sans compter, il me semble, qu'il ne compile pas de code ObjectiveC.
Pour info, Cocoa marche très bien avec Codewarrior. je ne vois pas pourquoi Core Data et Core Image ne fonctionnerait pas avec CodeWarrior également. Pour les bindings, je ne sais pas s'il fonctionnent avec CodeWarrior, mais Didier pourra certainement répondre sur ce point.
Pour ma part, j'avoue préférer XCode, mais c'est surtout parce que j'avais trouvé CodeWarrior assez compliqué. Par contre, le temps de compilation est très important et il est indéniable que CodeWarrior va plus vite.
J'attends également les liens vers de grosses appli développées avec XCode. Ce n'est pas que je doute qu'il y en ait, mais il faut bien prouver ses arguments.
SuperCed a dit:
Encore une fois, on répond à coté ... Relis donc ce que didier affirme ... XCode ne sait gérer que des "grigris" ... tu vas page 1 et tu t'appliques.
XCode a des défauts dont la necessaire config musclée qui est demandée.
Maintenant si tu veux développer un projet pure Cocoa d'envergure, utilisant des technos d'avenir (surtout le couple coredata+bindings par exemple) et que tu utilises CW pour ca...je suis TRES interessé à voir le résultat
d'ailleurs j'attends encore des exemples d'envergure non-carbon de la part de didier...Merci d'avance.
Bonjour,
Oui, les headers précompilés ont bien aidé en terme de rapidité. Egalement XCode compile, si j'ai bien compris, en utilisant les deux processeurs (une tache GCC compile un fichier, ce qui compile deux fichiers simultanement)
Pour les bindings, je ne sais pas, je n'ai jamais pratiqué et j'evite de parler de ce que je connait pas...
En fait, le compilateur de CW a été developpé par des types de Motorola et les optimisations sont plutot poussées que ce soit en terme de vitesse de compilation que de code obtenu.
Cordialement
Oui, les headers précompilés ont bien aidé en terme de rapidité. Egalement XCode compile, si j'ai bien compris, en utilisant les deux processeurs (une tache GCC compile un fichier, ce qui compile deux fichiers simultanement)
Pour les bindings, je ne sais pas, je n'ai jamais pratiqué et j'evite de parler de ce que je connait pas...
En fait, le compilateur de CW a été developpé par des types de Motorola et les optimisations sont plutot poussées que ce soit en terme de vitesse de compilation que de code obtenu.
Cordialement
cretinoïde a dit:
Tu risque d'attendre longtemps, puisque c'est a toi de les fournir...
Cordialement
Didier Guillion a dit:
tu veux de gros projets développés sous XCode ?
Toutes les applis Apple (et ca en fait des grosses, des moins grosses et des enormes sans compter les frameworks), les applis Omnigroup, les applis nisus, les applis Filemaker et j'en passe et des meilleurs.
Il faut savoir qu'une appli comme ComicLife dépasse allègrement les 150 000 lignes d'obj-c idem pour rapidweaver...ce ne sont pas de "petits" projets malgré leur status de shareware.
Tu veut dire que tu as travaillé pour toutes ces boites ?
Ou alors tu as seulement "entendu dire que..." ?
Et ils sont content de XCode ?
Ou alors ils l'utilisent car ils n'ont pas le choix ?
Concretement, la derniere appli que tu as ecrite, c'est quoi ?
Cordialement
Ou alors tu as seulement "entendu dire que..." ?
Et ils sont content de XCode ?
Ou alors ils l'utilisent car ils n'ont pas le choix ?
Concretement, la derniere appli que tu as ecrite, c'est quoi ?
Cordialement
je suis TRES interessé à voir le résultat
J'en connais au moins un puisque j'avais participé au développement :
http://www.xstoner.com/
C'est un projet Cocoa, on le compilait aussi bien sous XCode que sous CodeWarrior, avec de très petites adaptations. Je ne me souviens plus si l'appli finale a été compilée avec gcc ou CodeWarrior, mais dans les 2 cas, ça fonctionnait très bien.
Et je répète que je ne vois pas ce qui empêcherait Codewarrior d'utiliser Core Image ou Core Data. Ce ne sont qude des frameworks, il n'y a pas de raison que ça ne fonctionne pas a priori.
Didier Guillion a dit:
Globalement, XCode est un produit tres abouti. C'est juste un veau te diront tous ces gens à la WWDC. D'ailleurs, il me semble pas t'avoir vu lors de la derniere session...
Bonjour,
Concernant, XCode moi j'aime bien ... surtout parce que c'est gratuit. Je ne l'ai pas utilisé sur de gros projets donc je ne ferai pas de commentaires. Mais j'ai travaillé avec des IDE bien plus abouties comme IntelliJ, malheureusement c'était pour du Java Donc je dirais juste qu'il reste du boulot à Apple pour en faire la meilleure IDE du monde.
Je vous laisse continuer votre discussion
Tout à fait, et je pense que sur un Quad, il doit être capable de compiler 4 fichiers simultanément. Qui a essayé ?Didier Guillion a dit:
Concernant, XCode moi j'aime bien ... surtout parce que c'est gratuit. Je ne l'ai pas utilisé sur de gros projets donc je ne ferai pas de commentaires. Mais j'ai travaillé avec des IDE bien plus abouties comme IntelliJ, malheureusement c'était pour du Java
Donc je dirais juste qu'il reste du boulot à Apple pour en faire la meilleure IDE du monde.Je vous laisse continuer votre discussion
Et bein... pour une discussion relevée... on est servi
Bon, personnellement, je ne suis qu'un très modèste débutant autodidacte, donc, pas très au fait de toutes le particularité techniques concernant le développement d'applications...
Je constate, toutefois, que les développeurs chévronés semblent plus préocupés par les aspects technologiques offerts par les environnements de développement, ce qui semble logique après tout, plutôt que par l'aspect purement ergonomique des applications en question...
Or, pour ma part, bien que je fasse mes petits "gris-gris" sans aucune prétention avec XCode, je reste persuadé que côté ergonomie on peut faire bien mieux, car, franchement, je ne trouve pas ce logiciel particulièrement productif...
Alors, je me demande, sérieusement, si les grosse boîtes qui travaillent avec XCode (il y en a certainement), n'ont pas, pour leur usage interne, des utilitaires ou plug-ins qui rendent le travail avec XCode en peu plus facile, réactif et productif... qu'en pensez-vous ?
a+
Bon, personnellement, je ne suis qu'un très modèste débutant autodidacte, donc, pas très au fait de toutes le particularité techniques concernant le développement d'applications...
Je constate, toutefois, que les développeurs chévronés semblent plus préocupés par les aspects technologiques offerts par les environnements de développement, ce qui semble logique après tout, plutôt que par l'aspect purement ergonomique des applications en question...
Or, pour ma part, bien que je fasse mes petits "gris-gris" sans aucune prétention avec XCode, je reste persuadé que côté ergonomie on peut faire bien mieux, car, franchement, je ne trouve pas ce logiciel particulièrement productif...
Alors, je me demande, sérieusement, si les grosse boîtes qui travaillent avec XCode (il y en a certainement), n'ont pas, pour leur usage interne, des utilitaires ou plug-ins qui rendent le travail avec XCode en peu plus facile, réactif et productif... qu'en pensez-vous ?
a+
Didier Guillion a dit:Bonjour,
Oui, les headers précompilés ont bien aidé en terme de rapidité. Egalement XCode compile, si j'ai bien compris, en utilisant les deux processeurs (une tache GCC compile un fichier, ce qui compile deux fichiers simultanement)
Pour les bindings, je ne sais pas, je n'ai jamais pratiqué et j'evite de parler de ce que je connait pas...
En fait, le compilateur de CW a été developpé par des types de Motorola et les optimisations sont plutot poussées que ce soit en terme de vitesse de compilation que de code obtenu.
Cordialement
Personne n'a nié que le compilo de CW n'était pas optimisé ou tres optimisé (d'ailleurs aussi bien à la compile qu'à l'execution). GCC pour PPC est une catastrophe niveau optimisation, ce n'est pas nouveau. Avec la V4, on a du gagner 20 à 30 % à l'exécution mais bien peu à la compile. Aujourd'hui dans ma boite aucune station G5 n'est équipée avec moins 3 Gb de Ram. C'est le confort minimum pour bosser confortablement avec XCode et bénéficier en retour de possibilités complement tournées vers l'avenir d'OS X.
D'ailleurs en parlant de GCC, avec le passage sur X86 on va sentir la différence (ou on le sent deja pour ceux qui ont la DTK).
Est-ce que c'est gcc le problème ou le fait que XCode le relance pour chaque fichier qu'il doit compiler ? Car assurément si c'est cela, il faudrait qu'Apple trouve une autre méthode, comme réécrire un compilateur basé sur gcc mais qui ne se lance qu'une seule fois en prenant d'emblée tous les fichiers à compiler.
ntx a dit:
Sincèrement, je ne pense pas que le temps de chargement de GCC soit significatif dans la durée totale de traitement. C'est plutot, GCC lui meme qui n'est pas tres rapide.
Cordialement
Bonsoir et Joyeux Noel,
Apparemment, si j'ai bien compris, Intel serait en train de porter ses outils de développement sur Mac OS X, ce qui serait un substitut au passage obligé sur XCode !
Excellente nouvelle !
"Intel Corp. will port its software developer tools to Mac OS X and will ship its first beta later this year, the chip maker told developers on Tuesday at its first-ever session on Mac OS X at the Intel Developer Forum in San Francisco."
http://www.eweek.com/article2/0,1895,1851752,00.asp
L'information date d'Aout, mais je ne l'ai sous les yeux que maintenant. Je ne sais pas comment cela a évolué.
A suivre...
Cordialement
Apparemment, si j'ai bien compris, Intel serait en train de porter ses outils de développement sur Mac OS X, ce qui serait un substitut au passage obligé sur XCode !
Excellente nouvelle !
"Intel Corp. will port its software developer tools to Mac OS X and will ship its first beta later this year, the chip maker told developers on Tuesday at its first-ever session on Mac OS X at the Intel Developer Forum in San Francisco."
http://www.eweek.com/article2/0,1895,1851752,00.asp
L'information date d'Aout, mais je ne l'ai sous les yeux que maintenant. Je ne sais pas comment cela a évolué.
A suivre...
Cordialement
N
Nicky Larson
Invité
Pas mal pas mal.
Si j'ai bien compris, tu ne connais pas du tout les outils de développement d'Intel, mais ça sera forcément mieux que Xcode...
Enfin désolé de te casser tes rêves, mais apparemment les outils d'Intels ne seront pas un substitue à Xcode, mais des plug ins pour Xcode afin d'améliorer les performances du code généré.
Il semble que tu seras obligé de passer à Xcode, ou d'arrêter de programmer sur mac.
Pas vraiment, il parle de ça.
Mais bon, c'est vrai que toi t'es "un professionnel" comme tu le dis si souvent, chez Aspyr c'est que des amateurs...
Si j'ai bien compris, tu ne connais pas du tout les outils de développement d'Intel, mais ça sera forcément mieux que Xcode...
Enfin désolé de te casser tes rêves, mais apparemment les outils d'Intels ne seront pas un substitue à Xcode, mais des plug ins pour Xcode afin d'améliorer les performances du code généré.
Il semble que tu seras obligé de passer à Xcode, ou d'arrêter de programmer sur mac.
Didier Guillion a dit:
Pas vraiment, il parle de ça.
http://developer.apple.com/business/macmarket/aspyr.html
Mais bon, c'est vrai que toi t'es "un professionnel" comme tu le dis si souvent, chez Aspyr c'est que des amateurs...
Nicky Larson a dit:
Tu me cherche mon gars ? Alors essaie d'être un minimum subtil, parce que la, j'ai deja vu.
Cordialement
Je ne comprends pas une chose. Il me semblait que Apple se mettait a fond sur GCC4, pour PowerPC mais aussi pour x86. Si Intel sort des plugins pour Xcode, ce sera necessairement au niveau compilateur, donc un concurrent de GCC4. Est-ce que Apple est capable de gerer deux compilateurs de front ? Est-ce que GCC4 n'etait qu'un coup de bluff ? Les compilateurs Intel sont remarquables (en tout cas sur Intel), il faut avoir programme sous Linux et GCC3 ou 4 pour comprendre l'avancee de Intel sur les autres.
Au passage, il y a cette histoire de Ars Technica (merci de ne pas trop leur taper dessus, je les tiens pour d'excellents analystes pro-Mac grace a leur sens des realites), en juillet je crois, qui disait qu'un developpeur interne de Apple etait degoute parce que l'OS est compile avec des optimisations au niveau de la taille des programmes, pas du tout au niveau de la rapidite / reactivite. On en est ou, ca reste d'actualite ?
Au passage, il y a cette histoire de Ars Technica (merci de ne pas trop leur taper dessus, je les tiens pour d'excellents analystes pro-Mac grace a leur sens des realites), en juillet je crois, qui disait qu'un developpeur interne de Apple etait degoute parce que l'OS est compile avec des optimisations au niveau de la taille des programmes, pas du tout au niveau de la rapidite / reactivite. On en est ou, ca reste d'actualite ?
Apple gère deja plusieurs compilateur dans XCode, puisque l'on a le choix entre GCC3 et GCC4. Il n'y aurait donc a priori, aucun probleme pour ajouter le compilateur Intel dans la liste. (Considere qu'XCode est une interface graphique qui invoque des lignes de commande shell, un compilateur est juste un exécutable lancé avec une liste de commandes)HmJ a dit:
C'est en effet au niveau de la vitesse de compilation et de l'optimisation du code qu'Intel peut apporter un gros plus.
Je ne sais pas, je n'ai pas d'informations la dessus.
Cordialement
