Distribution - Page 4

Kakuzei> moi suis allé chez Apple pour comparer... mettre entre 300 et 500 euros en plus pour la même chose m'a un peu rebuté.
Et à la question sur MacOSX, lui disant être sous linux, le vendeur me montra toutes les applications qu'on retrouve dans KDE, me disant que je peux aussi installer KDE sur mon mac, me faisant juste la démo des jolies animations du gestionnaire de fenêtres.
Merci, mais pour changer de fenêtre joliement, ça fait cher la différence avec linux gratuit... :P

Sous linux tu as Office ?

Tu as toute les appli professionelle comme Photoshop, Dreamwaeaver & Co ?

oui ! (capture de début d'année)


Dreamweaver, Photoshop, Office...

Wine avec tout les bugs qui en incombent lol

Moi je parle d'application NATIVE pas d'une émulation plus ou moins foireuse hein.

Wine marche jusqu'au moment ou il ne marche plus (hum philosophique ma phrase )

Et puis j'adore comme même les linuxiens sont jaloux de MacOS X et d'Aqua

Depuis j'ai changé de thème ne t'en fais pas...

ensuite consernant wine, c'est à Codeweaver Crossover que je le dois, donc il sait le configurer. Je n'avais pas de pb avec. Et je ne fais pas du photoshop ni du dreamweaver tous les jours...

Et je ne fais pas du photoshop ni du dreamweaver tous les jours...

moi si (sauf que tu remplaces dreamweaver par illustrator ou painter). donc linux, poubelle direct. c'est dommage, parce que j'aurais rien contre :/

oui c'est sûr...

Kakuzei
:

Défis : en combien de temps boote win3.11 sur un P4?

Je propose autre chose : défis : installer win3.11 sur un P4

Sur une machine virtuelle il faudrait que j'essai mais je n'ai pas windows 3.11.

En même temps, win 3.11 n'est pas un OS.

Tien c'est bisard mais comme d'hab tu t'es planté, c'est la version 2.0.
D'ailleur entre la 1.1 et la 2.0 j'ai toujours trouvé les memes bugs, et quand je dit bug c vraiment bug: refresh inexistant (faut surligner pour que la coloration syntaxique marche... ) quand on split la fenetre il rafraichit pas du coup on pense ecrire sur qqc... ca ecrit, on surligne, ho ct 300 lignes plus bas que j'ecrivais...
sans compté la femeture d'Xcode parce qu'on compile... (mac c'est comme windows, ca plante, mais la diff c que ca vous le dit pas... )
Bref ton argumentation ne tiens pas bcp debout... peut etre que j'ai passé plus d'h que toi sur XCode pour pouvoir annonce que c de la merde. Oui au premier abord ca semble bien, tout rempomper sous VC++ mais finanlement niette.

Mais de toute Apple sait gagner de l'argent: difference entre Tiger et panter? pas grand chose qui justifie de payer ce prix (d'ailleur bcp de fonctionnailités sont meme pas géré par les ibook et compagnie -> cg de merde normal).
Si j'avais le choix j'aurais pris un centrino mais j'ai fait l'erreur de croire les mensonges des macusers.
Ha oui et tiger est lui aussi loin d'etre bug free!

(de toutes façons, godzil et MacOS c'est comme spectras et linux ou vince et Windows ^^)

moi perso je tourne sur les 3...

JackosKing :
Tien c'est bisard mais comme d'hab tu t'es planté, c'est la version 2.0.

Ha ben tant mieux pour toi alors

D'ailleur entre la 1.1 et la 2.0 j'ai toujours trouvé les memes bugs, et quand je dit bug c vraiment bug: refresh inexistant (faut surligner pour que la coloration syntaxique marche... )

Jamais eu de pbm significatif avec la coloration syntaxique, jamais plus qu'avec n'importe quel éditeur, celui de Visual Studio compris

quand on split la fenetre il rafraichit pas du coup on pense ecrire sur qqc... ca ecrit, on surligne, ho ct 300 lignes plus bas que j'ecrivais...

Ha ben si tu met pas le curseur d'insertion ou il faut hein c'est de ta faute hein

sans compté la femeture d'Xcode parce qu'on compile... (mac c'est comme windows, ca plante, mais la diff c que ca vous le dit pas... )

Heu alors la, tu n'a jamais utilisé MacOS pasqu'une appli qui plante, il te le dit hein
Et je n'ai jamais eu depuis les premiere version de XCode en passant par toutes les version de GCC qui on été disponible, mais alors JAMAIS eu un seul plantage de XCode lié a gcc, et pourtant j'en ai compilé des choses

Bref ton argumentation ne tiens pas bcp debout... peut etre que j'ai passé plus d'h que toi sur XCode pour pouvoir annonce que c de la merde. Oui au premier abord ca semble bien, tout rempomper sous VC++ mais finanlement niette.

Hum ta passé plus d'heure ? je demande a voir tu sais.

XCode 2 j'y ai goûté alors que tu ne savais même pas ce que tiger était, et XCode 1.1 et 1.5 j'y ai goûté quasiment depuis leurs sorties (depuis 10.3 quoi)

XCode a encore beaucoup d'erreurs de jeunesse, et c'est normal, Visual Studio n'etait pas parfait des le départ (et il ne l'est toujours pas parfait)

XCode est très loin d'être un pseudo repompage de visual studio, je vois vraiment pas ou tu es allez pécher ça. C'est plutôt une évolution du Macintosh Programmer Workshop (chose que tu ne me semble pas du tout connaître, surtout vu ta culture du monde MacOS)

Mais de toute Apple sait gagner de l'argent: difference entre Tiger et panter? pas grand chose qui justifie de payer ce prix (d'ailleur bcp de fonctionnailités sont meme pas géré par les ibook et compagnie -> cg de merde normal).

cg de merde, sache qu'il y a 2ans (fin 2003) les ATI 9200 était pas "de la merde". les iBook commence a se faire vieux, faut pas s'étonner que la carte soit pas reconnus par Quartz 2D Extreme (qui encore une fois je le rappelle n'apporte RIEN d'interessant, seul Core Image a un intérêt, mais il est capable d"utiliser le CPU si besoin au lieu du GPU)

Et tu t"y connais bien mal aussi en OS. Tiger apporte une véritable révolution, que panther n'avais apporté que de l'évolution. Bien sur pour un utilisateur qui comprend rien, il ne verra pas de différence, c'est sur, c'est d'ailleurs la ou apple joue très bien son role. Les changement sont pourtant radicaux, mais l'utilisateur final ne s'en rend même pas compte !

Si j'avais le choix j'aurais pris un centrino mais j'ai fait l'erreur de croire les mensonges des macusers.

Ya quelqu'un qui t'a mis un couteau sous la gorge et qui t'a dit "Achete un mac ou je te tue" ? non ? bon alors ferme la.

Ha oui et tiger est lui aussi loin d'etre bug free!

Qui a dit qu'il etait bug free ? Personne a ma connaissance, et surement pas moi

Tu trouve que linux est bug free ? Windows bug free ? non ?
Ben encore un argument qui ne tiens pas la route...

C'est marrant mais plus je discute avec toi, et plus je sens une forme de mauvaise foi inouïe...

Et Nil: tres malin

JackosKing :
moi perso je tourne sur les 3...

Et tu crois être le seul ?

Tu as commencé a utiliser un mac quand ? Linux quand ? Windows quand ? (et commencé a programmer sur chaque quand ?)

Godzil :
Et Nil: tres malin

en meme temps c'est vrai

Nil :
(de toutes façons, godzil et MacOS c'est comme spectras et linux ou vince et Windows ^^)

Peio
:

Godzil :
Et Nil: tres malin

en meme temps c'est vrai

Non je defend autant MacOs que windows, et linux dans une certaine mesure

Vu tes arguments: faut mettre le curseur au bon endroit... bien apprend a lire.
C'est le premier editeur ou il faut que je surligne pour voir ce qui est marqué (enfin ce qui est vraiment marqué, parce que c pas refresh..).

Les ibooks se font vieux... louche ils en vendent toujours... et avec la meme carte depuis des lustres (et pourtant ils ont fait bcp de release depuis... mais forcement ils sont radins comme tout. La preuve, la baisse de qualité des ecrans de portable apple depuis la derniere generation (speciale dedicaces aux pb).
J'ai fait toute mon année de prog sur mon ibook enfin quand je le pouvait parce que pour faire de l'opengl sous osX faut etre sado maso (90% de puissance pompé par le system, le reste vu la carte graphique ... faut pas s'attendre a grand chose).
Et Non Tiger/panther ne présise pas tout le temps... tout depend le plantage.

Ce qui m'a fait prendre un mac, c'est les faux arguments a 2centimes de beaucoup de mac'users...

Godzil
:

PpHd
:

(perte du 64Bits)

#triconfus# T'es sur ? amd64/emt64 ca existe depuis un certain temps. Le temps qu'apple prenne des intel, ca sera encore plus repandu.

Oui la roadmap d'intel est pas encore pour le 64b partout, et les consignes d'apple pour la transition vers Intel ne fait mention nulle par du 64Bit, ce qui veux bien dire ce que ça veux dire...

Ben pour savoir si ce qu'il en est c'est simple, il suffit de voir si XCode version PPC+x86 génère du code IA-32 et/ou AMD64... Tu l'as ou c'est réservé aux kits de dév ?

Les ibooks se font vieux... louche ils en vendent toujours... et avec la meme carte depuis des lustres (et pourtant ils ont fait bcp de release depuis... mais forcement ils sont radins comme tout. La preuve, la baisse de qualité des ecrans de portable apple depuis la derniere generation (speciale dedicaces aux pb).

Apple n'est pas le seul a être touché par la basse de qualité des LCDs, tout les portables et tout les écrans le son, forcement on vend plus de dalles, faut en fabriquer plus donc les contrôles sont moins poussé, et encore plus sur les grandes dalles

Les iBooks n'ont subit depuis l'arrivé de l'iBook G4 que des évolution mineurs (augmentation du processeur), même entre l'iBook G3 et le G4 les différences ne sont pas énormes.

Pourquoi il se vendent aussi bien ? La raison est très simple, techniquement les iBook et les powerbook sont très proche (du moins c'était vrai il y a peu les PB on maintenant des cartes vidéo un peu plus poussé, mais a pars ça) et la différence de prix entre un iBook et un PB n'est pas justifié (surtout sur les modèles 12"). J'ai discuté avec un vendeur il y a quelques mois en arrière et m'a confirmé que ce qui poussait les gens a prendre un iBook par rapport a un PB ce n'est uniquement que le PRIX !

Et si tu parle de qualité, Apple n'a pas toujours fait preuve de qualités hein. Tu connais bien mal ce monde ça se vois..

A l'époque pendant la transition 68k/PPC, c'était une époque ou Apple avait plus d'une trentaines de machines au caractéristiques proche et différentes a la fois. Certaines était de très bonne facture (les Quadras/Centris en sont encore la preuve) et d'autre des bouses immondes instables etc.. (certain LC entre autres) et la même chose c'est répété avec les machines 100% PowerPC, jusqu'au moment ou SJ est revenu à Apple et à fait clarifier la gamme en coupant celle-ci en 4 domaines : Portable Grand public (iBook) et Pro (PowerBook) Machine de bureau grand public (iMac) et Pro (PowerMac)
Depuis la gamme bureau c'est un peu plus confuse (on peu dénombrer 4 types de machines, le Mac Mini, les eMac, l'iMac et le PowerMac qui on chacun un domaine assez flou les iMac sont plus les machines très grand public qu'elles étaient avant etc..)

Pour en revenir à la fiabilité/qualité de fabrication, tu n'as pas connu les Powerbook Titanium. Des vrais merdes, peinture qui se barre au bout de quelques mois, la trappe d'accès au connecteurs qui se casse facilement etc... (sans compter plantages car la carte mere n'est pas stable et j'en passe)

Donc, certain (dont tu fait plus ou moins partit) on beau se voiler la face, apple n'est pas forcement gage de stabilité. Certaines machines oui, sont très stable et de tres grande qualitée. D'autres non et sont vite partit dans les oubliettes (le Cube G4 par exemple, c'est un tres bon exemple, il est resté sur le catalogue a peine quelques mois)

J'ai fait toute mon année de prog sur mon ibook enfin quand je le pouvait parce que pour faire de l'opengl sous osX faut etre sado maso (90% de puissance pompé par le system, le reste vu la carte graphique ...

Bizzare parce que tout les jeux et applis que j'ai vu fonctionner avec OpenGl, et ne demandant pas 95% de CPU à elles seule n'ont jamais eu besoin de faire dépasser le CPU a plus de 5 a 10%, et les FPS & co sont très bonnes, bref. C'est ptet toi aussi qui développe pas correctement en OpenGL, tu ne t'es pas posé la question ? Comment il font les Autres ??

Quand au fait que l'OS "pompe" 90% de la "puissance", Quartz Extreme utilise Open GL pour le rendu des fenêtres oui, mais quand tu as une fenêtre plein ecran, ou que tu fait un rendu dans une fenêtre, Quartz Extreme sait s'effacer et n'est pas utilisé dans ce genre de cas.

Aussi va me trouver un OS capable d'afficher une fenêtre OpenGL sur 2 écran (ou plus) simultanément

edit: oui je pensait, je connais la 9200 et sa "bonne" réputation et curieusement j'ai quand même été surpris, certes c'est pas un jeu très récent, mais Warcraft 3 qui tournait avec beaucoup de mal sur ma GForce 2 TI fonctionne sur mon mac avec une ATI 9200 a plein régime tout les options à fond. Bizzare quand même pour un système qui pompe 90% des ressources du GPU non ? (et faut pas oublier que War3 est développé avec Carbon, de telle manière qu'il fonctionne indifféremment sous un OS 9 ou sous OS X (ce qui est un facteur pouvant mener a un ralentissement)

faut pas s'attendre a grand chose).
Et Non Tiger/panther ne présise pas tout le temps... tout depend le plantage.

TOUS les plantages sont reporté, sans exceptions. Il n'existe pas 36 millions de sorte de plantages. Sa plante ou ça ne plante pas point

Ce qui m'a fait prendre un mac, c'est les faux arguments a 2centimes de beaucoup de mac'users...

Oué bref c'est l'argument du couteau sous la gorge quoi, bref

Pollux
:

Godzil
:

PpHd
:

(perte du 64Bits)

#triconfus# T'es sur ? amd64/emt64 ca existe depuis un certain temps. Le temps qu'apple prenne des intel, ca sera encore plus repandu.

Oui la roadmap d'intel est pas encore pour le 64b partout, et les consignes d'apple pour la transition vers Intel ne fait mention nulle par du 64Bit, ce qui veux bien dire ce que ça veux dire...

Ben pour savoir si ce qu'il en est c'est simple, il suffit de voir si XCode version PPC+x86 génère du code IA-32 et/ou AMD64... Tu l'as ou c'est réservé aux kits de dév ?

IA32 (et le jour ou un mac aura de l'Athlon (XP ou 64) c'est qu'amd aura ses propres usines et ferra quelque chose de potable pour les machines portables)
Et je l'ai

je peut te faire un neloworld si tu veux (bouge pas )


Alors :

#include <stdio.h>

int main (int argc, const char * argv[]) {
    printf("NeloWorld!\n");
    return 0;
}

Architecture "i386" (ça veux tout dire)

(lignes de compilation)

Native Build of Target "NeloWorld" using Build Configuration "Release"
Distributed-CompileC build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386/main.o main.c normal i386 c com.apple.compilers.gcc.4_0
    mkdir /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386
    cd /Users/godzil/NeloWorld
    setenv DISTCC_HOSTS "192.168.1.42:3632 "
    setenv MACOSX_DEPLOYMENT_TARGET 10.4
    /usr/bin/distcc /usr/bin/gcc-4.0 -x c -arch i386 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -Os -Wreturn-type -Wunused-variable -fmessage-length=0 -fvisibility=hidden -I/Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/NeloWorld.hmap -mdynamic-no-pic -fpch-preprocess -DMAC_OS_X_VERSION_MIN_REQUIRED=1040 -fconstant-cfstrings -D__CONSTANT_CFSTRINGS__ -F/Users/godzil/NeloWorld/build/Release -I/Users/godzil/NeloWorld/build/Release/include -I/Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/DerivedSources -isysroot /Developer/SDKs/MacOSX10.4u.sdk -s -c /Users/godzil/NeloWorld/main.c -o /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386/main.o

Ld /Users/godzil/NeloWorld/build/Release/NeloWorld normal i386
    mkdir /Users/godzil/NeloWorld/build/Release
    cd /Users/godzil/NeloWorld
    setenv MACOSX_DEPLOYMENT_TARGET 10.4
    /usr/bin/gcc-4.0 -o /Users/godzil/NeloWorld/build/Release/NeloWorld -L/Users/godzil/NeloWorld/build/Release -F/Users/godzil/NeloWorld/build/Release -filelist /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386/NeloWorld.LinkFileList -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk

Apres un

gcc main.c -S -arch i386 && cat main.s

	.cstring
LC0:
	.ascii "NeloWorld!\0"
	.text
.globl _main
_main:
	pushl	%ebp
	movl	%esp, %ebp
	pushl	%ebx
	subl	$20, %esp
	call	___i686.get_pc_thunk.bx
"L00000000001$pb":
	leal	LC0-"L00000000001$pb"(%ebx), %eax
	movl	%eax, (%esp)
	call	L_puts$stub
	movl	$0, %eax
	addl	$20, %esp
	popl	%ebx
	popl	%ebp
	ret
	.section __TEXT,__picsymbolstub2,symbol_stubs,pure_instructions,25
L_puts$stub:
	.indirect_symbol _puts
	call	___i686.get_pc_thunk.ax
LPC$1:	movl	L1$lz-LPC$1(%eax),%edx
	jmp	%edx
L_puts$stub_binder:
	lea	L1$lz-LPC$1(%eax),%eax
	pushl	%eax
	jmp	dyld_stub_binding_helper
	.section __DATA, __la_sym_ptr2,lazy_symbol_pointers
L1$lz:
	.indirect_symbol _puts
	.long	L_puts$stub_binder
	.subsections_via_symbols
	.section __TEXT,__textcoal_nt,coalesced,no_toc
.weak_definition	___i686.get_pc_thunk.ax
.private_extern	___i686.get_pc_thunk.ax
___i686.get_pc_thunk.ax:
	movl	(%esp), %eax
	ret
.weak_definition	___i686.get_pc_thunk.bx
.private_extern	___i686.get_pc_thunk.bx
___i686.get_pc_thunk.bx:
	movl	(%esp), %ebx
	ret

(j'ajoute encore qq bricoles.. 2 s)

Godzil :
IA32 (et le jour ou un mac aura de l'Athlon (XP ou 64) c'est qu'amd aura ses propres usines et ferra quelque chose de potable pour les machines portables)
Et je l'ai

Ben Intel fait aussi des processeurs 64 bits, hein (à part le Pentium M qui n'a pas encore les instructions kivonbien, mais ça devrait être résolu dans les générations à venir...)

Mais c'est dingue, ça veut dire que pdt un bout de tps ils vont se traîner des binaires 3x trop gros pour être compatibles PPC+x86+x86-64 ? (et qu'il vont devoir faire une autre transition 32->64 bits ^^)

Pollux
:

Godzil :
IA32 (et le jour ou un mac aura de l'Athlon (XP ou 64) c'est qu'amd aura ses propres usines et ferra quelque chose de potable pour les machines portables)
Et je l'ai

Ben Intel fait aussi des processeurs 64 bits, hein (à part le Pentium M qui n'a pas encore les instructions kivonbien, mais ça devrait être résolu dans les générations à venir...)

Mais c'est dingue, ça veut dire que pdt un bout de tps ils vont se traîner des binaires 3x trop gros pour être compatibles PPC+x86+x86-64 ? (et qu'il vont devoir faire une autre transition 32->64 bits ^^)

le EM-64 d'intel n'est pas encore officiellement en service hein...

ah bon y a pas plein de pentium qui marchent déjà en 64 bits ? p-ê qu'ils font pas encore bcp de bruit là-dessus parce que winxp 64 est pas encore sorti, mais ça viendra... et dans 1 an la situation sera différente ^^

Donc la suite :


(on vois clairement que la cible est du i386)

l'application une fois linké et tout :

http://www.godzil.net/dl.php?file=/public/tiger/NeloWorld

le fichier objet :

http://www.godzil.net/dl.php?file=/public/tiger/main.o

(ah tiens, j'imagine que c normal, mais ni l'exécutable ni le .o ne sont reconnus par file ou objdump ^^)

Forcement c'est du Mach-O

sache (quand meme) que a parts GCC, apple n'utilise aucune partie du toolchain de la FSF

iBookG4:~/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386 godzil$ file main.o 
main.o: Mach-O object i386
iBookG4:~/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386 godzil$

Et pour un Universal Binary :

iBookG4:~/NeloWorld/build/Release godzil$ file NeloWorld 
NeloWorld: Mach-O fat file with 2 architectures
NeloWorld (for architecture i386):      Mach-O executable i386
NeloWorld (for architecture ppc):       Mach-O executable ppc
iBookG4:~/NeloWorld/build/Release godzil$ 

(et la compilation ce fait en deux temps :

Distributed-CompileC build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386/main.o main.c normal i386 c com.apple.compilers.gcc.4_0
    mkdir /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386
    cd /Users/godzil/NeloWorld
    setenv DISTCC_HOSTS "192.168.1.42:3632 "
    setenv MACOSX_DEPLOYMENT_TARGET 10.4
    /usr/bin/distcc /usr/bin/gcc-4.0 -x c -arch i386 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -Os -Wreturn-type -Wunused-variable -fmessage-length=0 -fvisibility=hidden -I/Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/NeloWorld.hmap -mdynamic-no-pic -fpch-preprocess -DMAC_OS_X_VERSION_MIN_REQUIRED=1040 -fconstant-cfstrings -D__CONSTANT_CFSTRINGS__ -F/Users/godzil/NeloWorld/build/Release -I/Users/godzil/NeloWorld/build/Release/include -I/Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/DerivedSources -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c /Users/godzil/NeloWorld/main.c -o /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386/main.o

Ld /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386/NeloWorld normal i386
    mkdir /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386
    cd /Users/godzil/NeloWorld
    setenv MACOSX_DEPLOYMENT_TARGET 10.4
    /usr/bin/gcc-4.0 -o /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386/NeloWorld -L/Users/godzil/NeloWorld/build/Release -F/Users/godzil/NeloWorld/build/Release -filelist /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386/NeloWorld.LinkFileList -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk

Distributed-CompileC build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/ppc/main.o main.c normal ppc c com.apple.compilers.gcc.4_0
    mkdir /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/ppc
    cd /Users/godzil/NeloWorld
    setenv DISTCC_HOSTS "192.168.1.42:3632 "
    setenv MACOSX_DEPLOYMENT_TARGET 10.4
    /usr/bin/distcc /usr/bin/gcc-4.0 -x c -arch ppc -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -Os -Wreturn-type -Wunused-variable -fmessage-length=0 -mtune=G5 -fvisibility=hidden -I/Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/NeloWorld.hmap -mdynamic-no-pic -fpch-preprocess -DMAC_OS_X_VERSION_MIN_REQUIRED=1040 -fconstant-cfstrings -D__CONSTANT_CFSTRINGS__ -F/Users/godzil/NeloWorld/build/Release -I/Users/godzil/NeloWorld/build/Release/include -I/Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/DerivedSources -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c /Users/godzil/NeloWorld/main.c -o /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/ppc/main.o

Ld /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/ppc/NeloWorld normal ppc
    mkdir /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/ppc
    cd /Users/godzil/NeloWorld
    setenv MACOSX_DEPLOYMENT_TARGET 10.4
    /usr/bin/gcc-4.0 -o /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/ppc/NeloWorld -L/Users/godzil/NeloWorld/build/Release -F/Users/godzil/NeloWorld/build/Release -filelist /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/ppc/NeloWorld.LinkFileList -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk

CreateUniversalBinary /Users/godzil/NeloWorld/build/Release/NeloWorld normal "i386 ppc"
    mkdir /Users/godzil/NeloWorld/build/Release
    cd /Users/godzil/NeloWorld
    /usr/bin/lipo -create /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/i386/NeloWorld /Users/godzil/NeloWorld/build/NeloWorld.build/Release/NeloWorld.build/Objects-normal/ppc/NeloWorld -output /Users/godzil/NeloWorld/build/Release/NeloWorld

Bref si il faut 3h pour compiler la version PPC, il faudra 6h pour compiler la version un Universal Binary )

oué enfin ça c'est normal, hein surtout qu'il suffit de le faire une fois par release, c pas la mort ^^

ils auraient pu trouver un moyen plus inteligent (C -> Universal Object -> Archi précise) un peu comme le .Net framework et le MSIL..

ou le ByteCode du pascal

Ca veut dire :
- faire la compilation sur la machine de l'utilisateur : (sans compter des réticences qu'auraient les boîtes qui font des softs propriétaires)
- passer un tps fou à développer un code intermédiaire plus ou moins fumeux, plus ou moins efficace, et qui au final sera soit JITté (moins efficace, bouffe de la RAM, sauf si c'est vraiment bien implémenté), soit compilé traditionnellement sur la machine de l'utilisateur ()

Leur solution me paraît parfaitement logique... Ils sont capables de partager les données entre les version x86 et PPC ou pas ? (enfin c pas gravissime, puisque ça sera annulé par la compression, et un seul exemplaire sera en RAM, donc le seul pb est le tps d'installation ou l'espace disque, ce qui n'est plus trop un pb de nos jours, en tout cas pas pour les .exe)

Pollux :
Ca veut dire :
- faire la compilation sur la machine de l'utilisateur : (sans compter des réticences qu'auraient les boîtes qui font des softs propriétaires)
- passer un tps fou à développer un code intermédiaire plus ou moins fumeux, plus ou moins efficace, et qui au final sera soit JITté (moins efficace, bouffe de la RAM, sauf si c'est vraiment bien implémenté), soit compilé traditionnellement sur la machine de l'utilisateur ()

Leur solution me paraît parfaitement logique... Ils sont capables de partager les données entre les version x86 et PPC ou pas ? (enfin c pas gravissime, puisque ça sera annulé par la compression, et un seul exemplaire sera en RAM, donc le seul pb est le tps d'installation ou l'espace disque, ce qui n'est plus trop un pb de nos jours, en tout cas pas pour les .exe)

Nan ta pas compris ce que j'ai dit

Je parle pas de faire la compile coté utilisateur (ce que le .Net framework ne se gene pas pour d'ailleurs) mais de faire une compilation en passant par un format objet universel, et c'est généralement la compilation la plus "lourde" à faire et ensuite de ce code objet universel le convertir en code objet natif pour PPC ou pour i386 (ou les deux suivant les targets demandé)

(et partager les data entre x86 et PPC me semble assez loufoque a cause de l'endianess...)