Applications AppleScript Studio et MacIntel

[Didier Guillion]

Bonjour,

Continuant a explorer les nouveaux mécanismes des Universal Binaries, j'ai cherché a comprendre comment cela va fonctionner avec les applications AppleScript Studio.

Ce qui m'a mis la puce a l'oreille, c'est qu'AppleScript Studio n'est pas cité dans les environnements supportées par les Universal Binaries.
Cela voulait il dire qu'AppleScript Studio serait abandonné ?

En fait, voici ce que je pense, (merci de me contredire si vous avez des informations complementaires) : Les applications écrites avec AppleScript Studio sont déjà au format x86 et n'ont pas à être adaptées. En effet, le compilateur AppleScript Studio créé un fichier compilé qui est lui même interprété par l'interpreteur AppleScript. Le format de ce fichier est donc indépendant du processeur, c'est simplement l'interpréteur qui sera fourni en x86 par Apple.

Si c'est ca, c'est un grand ouf, sinon, je suis pommé...

Cordialement

 

[p4bl0]

Bonjour,

Continuant a explorer les nouveaux mécanismes des Universal Binaries, j'ai cherché a comprendre comment cela va fonctionner avec les applications AppleScript Studio.

Ce qui m'a mis la puce a l'oreille, c'est qu'AppleScript Studio n'est pas cité dans les environnements supportées par les Universal Binaries.
Cela voulait il dire qu'AppleScript Studio serait abandonné ?

En fait, voici ce que je pense, (merci de me contredire si vous avez des informations complementaires) : Les applications écrites avec AppleScript Studio sont déjà au format x86 et n'ont pas à être adaptées. En effet, le compilateur AppleScript Studio créé un fichier compilé qui est lui même interprété par l'interpreteur AppleScript. Le format de ce fichier est donc indépendant du processeur, c'est simplement l'interpréteur qui sera fourni en x86 par Apple.

Si c'est ca, c'est un grand ouf, sinon, je suis pommé...

Cordialement

ici, on est tous pommé


je ne suis sur de rien mais je pense que ce que tu dit est vrai : à priori, l'AppleScript et un language interprété, non?? et pour les projet AppleScript compilé, je ne sait pas, peut-être que c'est pas des fichiers binaires, mais un peut comme les applets java pour le web : un truc "compilé" et un interpréteur (javawebstart) qui lui est compilé pour les différents systèmes et architectures...


mais je ne suis sur de rien

 

[GrandGibus]

Sans répondre directement à Didier , une petite précision, en prenant le cas de Java:

On part de sources (fichiers .java), qui sont compilés pour être transformés en bytecode (fichiers .class). Jusque là, on est multi-platforme.

Ensuite viennent les interpréteurs: le JRE qui lui est dédié (un par platforme).

Pour l'anecdote, Java WebStart est une technologie de Sun qui est intégrée dans les navigateurs et qui permet au-dit navigateur d'interpréter un fichier (.jnlp) hébergé sur un serveur comme n'importe quelle autre resource telle pages html.... Ce fichier est en fait un simple fichier xml qui décrit l'environnement nécessaire à l'exécution d'un programme Java (le .jar d'une appli et les éventuelles librairies qui vont avec). Cette technologie présente surtout des avantages au niveau du déploiement d'applications.

Pour revenir à nos moutons, et si AppleScript n'usurpe pas son appelation script, il y a effectivement de forte chances pour que le seul changement de l'interpréteur en x86 suffise... mais je n'ai aucune preuve, juste des présomptions .

 

[Frodon]

Bonjour,

Je viens de regarder avec un exemple fourni par Apple (n'ayant personnellement pas encore développé avec AppleScript Studio): Daily Dilbert pour le pas le cité

Et visiblement ca se comporte comme n'importe quel autre projet XCode. C'est à dire qu'il faut selectionner le SDK MacOS X 10.4 (Universal) et l'architecture Intel (en plus de PowerPC), et compiler. Pour Daily Gilbert, ca ma fait un .app avec un Universal Binary sans problème:

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

Et apparement le fichier source qui sert à faire l'executable est toujours le même dans tous les projet AppleScript Studio (qui doit surement se contenter de lancer l'interpreteur AppleScript...?), enfin au moins pour les exemples.
Donc à priori devrait pas y'avoir de soucis pour compiler n'importe quel appli AppleScriptStudio en Universal Binary, puisque la seule chose qui pourrait dépendre du CPU c'est les quelques sources C ou Objective-C, mais si comme j'en ai l'impression il se résume toujours à la même chose (un petit main.m qui lance juste "ASKInitialize()") + un script AppleScript (qui lui n'a pas à être compilé donc pas non plus à être adapté pour Intel), ca devrait pas poser de prob ce genre de projet. Je me trompe?

A+

 

[Didier Guillion]

Bonjour,

Je viens de regarder avec un exemple fourni par Apple (n'ayant personnellement pas encore développé avec AppleScript Studio): Daily Dilbert pour le pas le cité

Et visiblement ca se comporte comme n'importe quel autre projet XCode. C'est à dire qu'il faut selectionner le SDK MacOS X 10.4 (Universal) et l'architecture Intel (en plus de PowerPC), et compiler. Pour Daily Gilbert, ca ma fait un .app avec un Universal Binary sans problème:

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

Et apparement le fichier source qui sert à faire l'executable est toujours le même dans tous les projet AppleScript Studio (qui doit surement se contenter de lancer l'interpreteur AppleScript...?), enfin au moins pour les exemples.
Donc à priori devrait pas y'avoir de soucis pour compiler n'importe quel appli AppleScriptStudio en Universal Binary, puisque la seule chose qui pourrait dépendre du CPU c'est les quelques sources C ou Objective-C, mais si comme j'en ai l'impression il se résume toujours à la même chose (un petit main.m qui lance juste "ASKInitialize()") + un script AppleScript (qui lui n'a pas à être compilé donc pas non plus à être adapté pour Intel), ca devrait pas poser de prob ce genre de projet. Je me trompe?

A+

Oui, c'est bien ce que je dit : ce ne serait pas la peine de creer un Universal Binaries, cela ne sert a rien si le projet ne comporte pas de C ou Obj-C.

Cordialement

 

[Frodon]

Bonjour,

ce ne serait pas la peine de creer un Universal Binaries, cela ne sert a rien si le projet ne comporte pas de C ou Obj-C.

A priori tu as au moins 1 fichier source en Objective-C qui Initialize AppleScript dans un projet AppleScriptStudio, main.m:

extern void ASKInitialize();
extern int NSApplicationMain(int argc, const char *argv[]);

int main(int argc, const char *argv[])
{
ASKInitialize();

return NSApplicationMain(argc, argv);
}

Donc faut faire au moins un Universal Binary pour ce fichier, sinon le .app resultant ne se lancera que sur Mac PowerPC, puisque c'est avec ce fichier source (main.m) que XCode de fait l'executable du .app qui lance ensuite le script.

A+

 

[Didier Guillion]

Bonjour,



A priori tu as au moins 1 fichier source en Objective-C qui Initialize AppleScript dans un projet AppleScriptStudio, main.m:

extern void ASKInitialize();
extern int NSApplicationMain(int argc, const char *argv[]);

int main(int argc, const char *argv[])
{
ASKInitialize();

return NSApplicationMain(argc, argv);
}

Donc faut faire au moins un Universal Binary pour ce fichier, sinon le .app resultant ne se lancera que sur Mac PowerPC, puisque c'est avec ce fichier source (main.m) que XCode de fait l'executable du .app qui lance ensuite le script.

A+

D'apres ce que j'ai compris, non.

Le "stub" va se lancer sous Rosetta puis le reste du programme sera interprété par l'interpreteur AppleScript x86.

Cordialement

 

[Frodon]

Bonjour,

D'apres ce que j'ai compris, non.

Le "stub" va se lancer sous Rosetta puis le reste du programme sera interprété par l'interpreteur AppleScript x86.

Cordialement

Ah oui, effectivement y'a toujours Rosetta. Mais bon rien n'empeche de faire un Universal Binary pour ce "stub", ca coute pas grand chose (à peine 1 sec de plus pour la compilation).

A+

 

[Didier Guillion]

Bonjour,



Ah oui, effectivement y'a toujours Rosetta. Mais bon rien n'empeche de faire un Universal Binary pour ce "stub", ca coute pas grand chose (à peine 1 sec de plus pour la compilation).

A+

Et ton appli ne fonctionne plus sous 10.2....

A mon avis, non, ce n'est pas une bonne solution.

Cordialement

 

[Frodon]

Bonjour,

Et ton appli ne fonctionne plus sous 10.2....

A mon avis, non, ce n'est pas une bonne solution.

Cordialement

Exact, sauf si tu t'embete à faite un Universal Binary composé d'un exe PPC compilé avec GCC3 pour 10.2+ et un exe i386 compilé avec GCC 4 à la main, avec la commande lipo (ou en faisant un script pour cela ou encore dans un Makefile).
Encore faut il verifier que MacOS X 10.2 supporte les Universal Binary (j'ai lu que oui, mais je n'ai pas pu le verifier moi même)

Mais bon il est vrai que ca n'en vaut pas forcement la peine.

A+

 

[Frodon]

Bonjour,

Il me semble cependant avoir lu dans le Universal Binary guide qu'il était possible de specifier des options de compilation différente par architectures (comme le SDK à utiliser ou les flags du compilateur) directement dans XCode, cela dit ce n'était pas très clair sur la façon de le faire dans le document

A+

 

[Frodon]

Bonjour,

Juste un petit post pour compléter ce que je disais precedement. Avec XCode 2.1, faire une application pour toutes les versions de MacOS X PPC et pour Intel en même temps était un peu fastidieux (en gros fallait faire de jolis scripts pour que la version PPC soit compilé avec une ancienne version de GCC en plus de selectionner le target SDK, et que la version Intel soit compilé avec GCC 4.0 (seule version publiquement releasé par Apple capable de compiler des applis pour Intel) puis en utilisant "lipo" pour faire l'Universal Binary final (scriptabel aussi evidement).

Et bien ceci est du passé dorénavant, car XCode 2.2, actuellement disponible en preview 1 sur ADC, permet de selectionner le compilateur de la version PPC et de la version Intel séparement, ainsi que d'autres options (le choix par architecture du target SDK était quant à lui déjà possible dans XCode 2.1). Bref, avec XCode 2.2, il est possible très simplement de faire uen version universelle pour toutes les versions de MacOS X (enfin, 10.1.5 et plus (si on recupere les XCode Legacy Tools. 10.2.8 et plus sinon)), car une fois les parametres selectionné correctement (en définissant les paramètres de build suivant: GCC_VERSION_i386, GCC_VERSION_ppc, MACOSX_DEPLOYMENT_TARGET_i386, MACOSX_DEPLOYMENT_TARGET_ppc, ce qui ne prend pas plus de quelques secondes et n'est à faire qu'une fois pour toute, par projet), une simple pression sur "Build" permet de générer un Universal Binary compatible MacOS X PPC 10.2.8+ (voir 10.1.5+ si les XCode Legacy Tools sont installées) et MacOS X Intel 10.4+.

PS: Je sais je suis en retard

A+

 

[tatouille]

Bonjour,

Juste un petit post pour compléter ce que je disais precedement. Avec XCode 2.1, faire une application pour toutes les versions de MacOS X PPC et pour Intel en même temps était un peu fastidieux (en gros fallait faire de jolis scripts pour que la version PPC soit compilé avec une ancienne version de GCC en plus de selectionner le target SDK, et que la version Intel soit compilé avec GCC 4.0 (seule version publiquement releasé par Apple capable de compiler des applis pour Intel) puis en utilisant "lipo" pour faire l'Universal Binary final (scriptabel aussi evidement).

Et bien ceci est du passé dorénavant, car XCode 2.2, actuellement disponible en preview 1 sur ADC, permet de selectionner le compilateur de la version PPC et de la version Intel séparement, ainsi que d'autres options (le choix par architecture du target SDK était quant à lui déjà possible dans XCode 2.1). Bref, avec XCode 2.2, il est possible très simplement de faire uen version universelle pour toutes les versions de MacOS X (enfin, 10.1.5 et plus (si on recupere les XCode Legacy Tools. 10.2.8 et plus sinon)), car une fois les parametres selectionné correctement (en définissant les paramètres de build suivant: GCC_VERSION_i386, GCC_VERSION_ppc, MACOSX_DEPLOYMENT_TARGET_i386, MACOSX_DEPLOYMENT_TARGET_ppc, ce qui ne prend pas plus de quelques secondes et n'est à faire qu'une fois pour toute, par projet), une simple pression sur "Build" permet de générer un Universal Binary compatible MacOS X PPC 10.2.8+ (voir 10.1.5+ si les XCode Legacy Tools sont installées) et MacOS X Intel 10.4+.

PS: Je sais je suis en retard

A+

oui cela revient à faire

* gcc-4 -arch i686 -arch ppc -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk toto.c -o toto

* gcc-4 -arch ppc -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk toto.c -o toto
* gcc-4 -arch i686 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk toto.c -o toto

*
* gcc-3.5 -arch i686 -Wl,-syslibroot,/Volumes/darwin_x86 toto.c -o toto
* gcc-3.5 -arch ppc -Wl,-syslibroot,/Volumes/darwin_ppc v.c -o toto
* gcc-3.5 -arch ppc64 -Wl,-syslibroot,/Volumes/darwin_ppc v.c -o toto


c'était déjà le cas avec opendarwin 7

* gcc-3.5 -arch ppc -arch i686 -Wl,-syslibroot,/Volumes/darwin_7_u toto.c -o toto

attention le linker gcc4-ld vous imposera un linkage à la libmx

si vous ne le voulez pas utiliser gcc-3.5
( version des developpers et qui n'est pas livré sur l'ADC)
mais vous remarquerez que tous les projets sources de darwin l'utilisent

gcc-3.5 (targets x86 et ppc comme gcc4)
vous pouvez récupérer un package comp

http://www.opendarwin.org/en/news/darwin801.html
/Volumes/Darwin8_$CPU/System/Installation/Packages_$CPU/gcc_os_35-3506.root.tar.bz2

pour l'appel de l'applescript
il est facile apprès compilation de ton projet avec xcode de faire

gcc-4 -arch i686 -arch ppc -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk main.m -o -framework ... carbon ,applescript ... MonAppLauncher et de le remplacer

pour java : JavaApplicationStub est déjà un fat binary

-extract your architecture from a binary

%$ lipo -info fat_binary.bundle
%$ lipo -extract i386 fat_binary.bundle -output fat_binary_i386.bundle

 

[Frodon]

Bonjour,

oui cela revient à faire

<zip>

Oui cela dit, cela reste quand même beaucoup plus simple avec XCode 2.2

En quelques seconde simplement en indiquant les variables suivantes dans les propriétés de build du projet:

GCC_VERSION_i386=4.0
GCC_VERSION_ppc=3.1
MACOSX_DEPLOYMENT_TARGET_i386=10.4
MACOSX_DEPLOYMENT_TARGET_ppc=10.1
SDK_ROOT_i386=/Developer/SDKs/MacOSX10.4u.sdk
SDK_ROOT_ppc=/Developer/SDKs/MacOSX10.1.5.sdk

Et en cliquant sur "Build" j'avais à l'arrivé un Fat Binary qui tourne à la fois sur MacOS X >=10.1.5 PPC et MacOS X i386 >=10.4

Sinon, GCC 3.5 que tu indique, ce qu'il compile se lancent sans soucis sur les vieilles version de MacOS X (<10.3.9. Bien sûr en targetant la bonne version de l'OS à la compile.)?

A+