Discussion :

[orthomimi]

Bonjour à toutes et tous

J'ai un souci : j'ai crée une petite application Applescript (bundle) mais l'essentiel du travail interne à ce bundle est fait par plusieurs éxécutables C qu'il contient, des sous-scripts Bash et surtout utilise le paquet GMP des grands nombres pour C. Aucune compilation à refaire donc, à priori.
Néanmoins alors qu'il fonctionne très bien chez moi, il ne fonctionne pas chez les autres...j'ai attribué cela au fait que le C, GCC et GMP ne sont pas installés en natif sur le Mac.
J'ai dù , en effet et depuis longtemps, installer ces trois paquets sur ma machine : pour le C et GCC je ne m'en souviens plus bien, cela fait un bail, pour GMP, j'étais passé par Brew.

Mes amis, qui ne sont que de simples utilisateurs, sont absolument terrifiés à l'idée d'aller sur le terminal puis ensuite sur Brew pour aller faire ces mises à jour, car ils ont la sensation qu'on va tout casser sur leur machine !

Je voudrai donc savoir comment intégrer directement à mon bundle les trois paquets applicatifs sus nommés et surtout comment mon programme pourra y accéder ensuite à partir du bundle, ce qui est le plus important.

Je ne pense pas que le C soit obligatoire pour faire fonctionner des programmes déjà compilés, mais comme GCC intègre lgmp en fin de compilation, il est peut être appelé par les éxécutables au moment des calculs ce qui expliquerait que l'absence d'installation de GMP, du moins de sa bibliothèque, interdit la bonne marche de l'application.

Quelqu'un pourrait-il me renseigner sur les modalités d'intégration de ces trois paquets, au moins sur celle de GCC et de GMP, dans un bundle Applescript ?

Un dernier point, je suis un rétrograde car j'utilise toujours Yosémite, et pour le reste Sublime Text et Script Debugger…et le terminal évidemment ( jamais Vi ou autre système, Sublime Text me suffit pour Bash et C ).
Par ailleurs le problème n'est pas dans la gène à l'ouverture d'une nouvelle application non Apple inscrite mais bien dans le fonctionnement de l'application elle même.

Je vous remercie par avance de vos suggestions

[PBELL]

Bonjour,
Je ne peux t'aider que sur une partie de ton problème: comment ajouter et utiliser des resources / bibliothèques intégrées dans ton application.

L'instruction Applescript "path to me" retourne le chemin vers ton application, où qu'elle soit enregistrée: n'importe quel Mac et n'importe quel dossier.
Le chemin est complet, c'est à dire débute à la racine du disque et se termine sur le "dossier" que constitue le paquet de ton application.

Par ailleurs, lorsque tu enregistres ton programme Applescript sous forme d'application, la structure de son contenu est immuable:
ton_application (le chemin path to me) -> sous dossier "Contents"

Dans Contents, il y a toujours au moins 4 items: Info.plist, dossier MacOS, Pkginfo et surtout un dossier Resources dans lequel tu peux ajouter ce que tu veux (en plus de ce qui existe par défaut).

Par exemple, lorsque j'ai besoin de bibliothèques Applescript que je ré-utilise d'un programme à l'autre, je les mets là. J'y mets aussi des icônes ou images dont j'ai besoin. Le chemin est alors:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set Chemin to ((path to me) as string) & "Contents:Resources:"

Avec cette instruction tu peux donc accéder à toutes les resources que tu auras ajoutées dans ton paquet d'application.

Les règles de sécurité impliquent que ces données soient en lecture seules. Si tu as des données à enregistrer (type préférences utilisateurs), il ne faut pas les mettre dans ton paquet. Sinon, à chaque ouverture de l'application, l'utilisateur aura une alerte indiquant que l'application a été modifiée.

Lorsque j'utilise des scripts avec des routines définies (mes bibliothèques de handlers), je mets ces bibliothèques dans le dossier Contents/Resource et j'utilise l'instruction Applescript Load (voir doc Applescript) en utilisant la technique du chemin ci-dessous.
Ma réponse s'arrête là. Je ne sais comment utiliser un paquet en C. Désolé.

Cordialement.

[orthomimi]

Merci encore de votre réponse si rapide et si claire.
Je vais continuer d'essayer de rechercher une bonne façon d'autonomiser mon application.
Très cordialement

[PBELL]

Bonjour,
Juste pour compléter: si tes modules C compilés peuvent être exécutés via le terminal en tapant une commande avec des paramètres (example 'mon_prgm_en_C var1 var2'), tu peux aussi le faire en Applescript, via la commande "do shell script" suivi de l'instruction complète.
Cette commande doit comporter le nom et chemin de l'exécutable, puis, comme d'habitude en shell, les paramètres séparés par des espaces si il y en a.
Le chemin de ton programme est connu avec la réponse que je t'ai donné hier. Il faut le convertir d'un format Finder (disque:dossier:fichier) à un format Unix (disque/dossier/fichier) ce qui se fait avec des 'posix' et 'posix path'.
Si des noms, dans le chemin, comportent des caractères tels que des espaces, utilise l'expression Applescript 'quoted form of' qui ajoute des guillemets pour éviter une interprétation erronée de la commande par le Shell.

J'ajoute que, si nécessaire, ton module C peut retourner un résultat, ne serait-ce qu'un code d'erreur (0=OK). Ce résultat est retourné dans le 'do shell script' et peut ensuite être utilisé dans ton script/application.

Précision: bien lire la documentation Apple à propos du 'do shell script' car l'environment n'est pas 100% identique à celui d'une fenêtre interactive du Terminal. Voire le lien ci-dessous.
https://developer.apple.com/library/...65/_index.html

Cordialement.

[orthomimi]

Bonjour et merci de vos réponses

Je reviens néanmoins vers vous et je vous mets, cette fois-ci, en PJ, le bundle en question : voyez si vous pouvez l'exécuter ou pas.
Il est très court mais il contient pourtant tous les exécutables c que j'utilise pour mon autre projet, donc si celui-ci fonctionne, l'autre fonctionnera aussi. ( c'est un mini-mini programme de cryptage )

Et encore merci de m'avoir répondu si longuement ( désolé de vous importuner le we ).

[PBELL]

voyez si vous pouvez l'exécuter ou pas

Bonsoir,
Par expérience, je n'exécute jamais un morceau de programme que je ne compile pas moi-même. Désolé.
J'ai cependant regardé la partie Applescript de ton application qui me semble parfaite.

Pour information, si tu n'as pas à définir les boutons de ton dialog (OK, Annuler). Ils existent par défaut.

J'ai même appris, grâce à toi que Applescript sait accéder directement au dossier ressources du paquet application avec path to resource "Script": Merci !!

Cordialement

[orthomimi]

Bonsoir

Oui je comprends, on ne sait jamais ce que peuvent contenir ces exécutables : je vais donc essayer de tester cela sur les membres de ma famille dont les machines constitueront d'excellents cobayes !

En fait j'utilise applescript depuis plus de 20 ans : je l'avais intégré à Filemaker pour le traitement et le stockage de mes photos…
Encore merci : j'ai lu aussi avec intérêt tes liens vers le "do shell script", cela fait réviser.

Merci encore

[orthomimi]

Bonjour

Je reviens vers vous ( je m'acharne ) avec un programme que j'ai cette fois simplifié à l'extrême.
Comme vous souhaitiez contrôler le programme C avant éxécution je vous propose :

1 ) ce programme en C : programme très simple de multiplication de deux chiffres de taille indéfinie qui utilise le paquet GMP et renvoie la valeur du produit des deux nombres passés en arguments : "multiplication.c."

Vous pourrez donc en vérifier le contenu avant sa compilation.

2 ) un bundle Applescript qui ne contient dans son dossier Scripts que ce même programme, non compilé : le bundle pourra effectuer ensuite toute l'opération et renvoyer le résultat de la multiplication dans une fenêtre "display dialog".

3 ) le "mode d'emploi" avec le détail de ce que contient et fait le bundle

Chez moi il fonctionne tout a fait normalement : pouvez vous m'indiquer quels problèmes vous rencontrerez en l'éxécutant et quels messages d'alerte vous verrez apparaître ?

Merci d'avance de vos réponses et surtout merci de m'avoir accordé quelques instants de votre temps.

[PBELL]

Bonsoir,

Pour t'aider, j'ai simulé, en lignes directes dans le terminal, les instructions de ton do shell script, sur le Mac de mon épouse (21' El Capitain, qui ne dispose d'aucun outil de développement).

La première commande Which=$(which which) renvoie bien le chemin de la commande which, soit "/usr/bin/which".
OK

J'ai testé la seconde commande avec gcc, ce qui renvoie bien le chemin attendu "/usr/bin/gcc".
OK

Le problème est à la 3ème instruction qui débute par Compil (c'est à dire /usr/bin/gcc) suivi des paramètres.
Si tout était parfait, en lançant seulement "/usr/bin/gcc", je devrai obtenir un message d'erreur car les paramètres de compilation sont manquants
En fait cette commande sur le Terminal retourne l'erreur suivante:
imac21:~ imac21$ /usr/bin/gcc
xcode-select: note: no developer tools were found at '/Applications/Xcode.app', requesting install. Choose an option in the dialog to download the command line developer tools.

Qui provoque aussi l'ouverture d'un dialogue pour obtenir et installer Xcode:
"Des outils de lignes de command sont nécessaires pour la commande <<gcc>>. Voulez vous les installer maintenant ?"

Ce dialogue affiche les boutons "Obtenir Xcode", "Plus tard" ou "Installer".

J'en déduis que, sur ton Mac, comme tu as déjà les utilitaires de programmation et de compilations installés, cela fonctionne.
Mais sur un autre Mac, non préalablement installé avec les utilitaires adéquats, cela ne peut pas fonctionner.
J'ai cherché rapidement sur le net et il semble que si ton programme en C est déjà compilé, tu n'as pas besoin de Xcode, mais il faut que le programme soit compilé correctement (mode release et SDK correct)
J'ai trouvé ce forum qui va peut être t'éclairer sur ce point.
https://forum.macbidouille.com/index...owtopic=388575

Bonne continuation

[orthomimi]

Je vais te poser une question bête ( je me permets de te tutoyer…) : as tu essayé le machin compilé sur l'ordinateur de ton épouse.

Car je pense que le souci ne doit pas être sur la compilation de démarrage mais dans les phases post compilation principales, phases ou l'éxécutable cherche les bibliothèques gmp et le <#include gmp.h>.

Ma question est donc la suivante.
Dois je, au moment de la compilation qui serait alors effectuée directement dans le dossier Scripts, écrire ceci : gcc multiplication.c -I include/gmp.h -L lib/libgmp.a -lgmp -o mul ( donc avoir deux dossiers en plus dans Scripts, lib et include, contenant les éléments de GMP ) et ensuite supprimer multiplication.c du dossier Scripts du bundle.
Je laisserai donc, à coté du futur éxécutable "mul" crée, les deux dossiers, include avec gmp.h, et lib avec les éléments du paquets lib de GMP, de façon à ce que l'éxécutable puissse ensuite retrouver ces deux éléments dont il se sert apparemment après la compilation principale, pour ses propres calculs.

Sur mon ordinateur il va les chercher tous deux dans /usr/bin je crois, en tous cas il sait ou les trouver.
Chez les autres , il pourrait à ce moment les retrouver dans le dossier Scripts ???.

Qu'en penses tu ?

[PBELL]

Bonjour,
Je comprends mieux que que tu veux dire (oui, le "tu" est parfait !).
Je n'avais pas compris que, post compilation, le programme faisait toujours appel aux librairies (je ne programme pas en c !).
Dans ce cas, le mieux est effectivement de ne pas faire d'hypothèse sur les fichiers/librairies qui pourraient exister sur le Mac.

Hormis les bibliothèques propre à Mac OS qui sont bien documentées par Apple, il faut supposer que le Mac ne contient rien d'autre !

Dans ce cas, effectivement, il faut compiler avec une référence explicite aux librairies et d'inclure celles-ci dans le paquet script. Tu peux tout mettre dans le dossier Resources ou dans un sous dossier de ton choix.
Cela va sans doute alourdir un peu le poids de ton application finale, mais permettra sa portabilité.

Bien que ne programmant pas en C (en fait tous les concepts sont un peu près les mêmes dans tous les langages), le compilateur C permet de définir les références en mode absolu ou en relatif. C semble appeler cela statique ou dynamique.

J'ai trouvé cela, qui ressemble à ton problème: https://cocoacafe.fr/index.php?p=/di...je-le-souhaite
Ou encore si tu pratiques l'anglais : https://gist.github.com/gubatron/32f82053596c24b6bec6

Si je comprends bien, il faut que tu passes toutes les "include" en dynamique avec un chemin relatif qui indique que leur dossier est le même que celui de l'exécutable C.
Si je comprends le principe, la mise en pratique dépasse mes compétences ! Désolé.

Cordialement

[orthomimi]

Bonsoir et encore merci de me soutenir dans l'effort

Je pense avoir entrevu ( enfin ) la solution : à force de trainer sur tous les forums, j'ai compris que le fichier posant problème était la librairie dynamique libgmp.10.dyllib qui se charge à la demande mais après la compilation : je vais donc faire au plus simple et donc faire un export PATH=adresse_librairie:$PATH ce qui va indiquer à l'exécutable d'aller chercher le chemin de la librairie dans le nouveau PATH donc à l'adresse indiquée qui sera un dossier du bundle.
En effet cette librairie est installé par défaut en /usr/local/lib par homebrew, et gmp va la chercher a cet endroit en premier.
Dès la session terminée tout s'effacera.
J'ai aussi trouvé des solutions plus compliquées mais je vais commencer par cela en attendant d'avoir tout compris ( dlopen(3) par exemple qui me semble diantrement complexe et qui, pour l'instant dépasse mes compétences ).

Le message d'erreur Applescript que m'a communiqué mon fils indique parfaitement que le logiciel cherche cette librairie : je te le passe en PJ.

Bon je pense que je vais m'en tenir là : au fait, dès la mise à jour de GMP effectuée par mon fiston, le logiciel a, bien entendu, parfaitement fonctionné, mais même lui, qui est ingénieur, ne savait pas trop comment s'y prendre avec Homebrew ( et puis il écrivait install avec un seul l !!! ).
J'essaierai donc de ne pas favoriser cette solution pour le tout venant.

Bien je te souhaite une bonne soirée et fin de week end et encore merci pour tout.

[orthomimi]

Bonsoir à toi

Voici la solution, je pense : elle repose sur la variable d'environnement DYLD_LIBRARY_PATH.
En effet cette variable correctement initialisée va indiquer au shell le chemin de la librairie dynamique de gmp : libgmp.10.dylib ( et des librairies dynamiques en général ).

Elle ne contient rien au départ.

Dans le dossier Scripts du bundle on place un dossier lib incluant la bibliothèque dynamique libgmp.10.dylib
On écrit ensuite:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
set mes_scripts to (path to resource "Scripts")
set mes_scripts_pos to POSIX path of mes_scripts
do shell script "cd " & quoted form of mes_scripts_pos &"
export DYLD_LIBRARY_PATH=lib:${DYLD_LIBRARY_PATH}
./programme_c
suite programme shell"

ce qui permet de pouvoir déplacer le bundle n'importe où sans être obligé de modifier le chemin absolu.

Le quoted form of est évidemment très important car il permet de se prévenir des chemins externes aux bundles pouvant contenir des espaces.

Comme la variable en question ( DYLD_LIBRARY_PATH ) est ré initialisée à la fermeture de chaque shell il faudra renouveler cet appel à l'ouverture de chaque nouveau shell.

Dans mon script, j'ai deux appels à do shell script, j'initialise donc deux fois la variable.
Ce qui est assez traitre c'est que je n'ai pas eu de message d'alerte au second shell alors que je ne l'avais pas fait au départ, mais évidemment sans réponse...

Pour aller un peu plus loin, et si il y a encore des amateurs de c et de gmp à cette heure tardive, il faut savoir que l'on peut très bien installer à part le paquet GMP dans un dossier_autre que le dossier par défaut (usr/local).

Ce dossier contiendra deux dossiers très importants : include et lib
Dedans, il y a des éléments appartenant au monde c++ que l'on peut retirer ainsi qu'un alias inutile de librairie.

Pour compiler il faut écrire précisément la séquence suivante : gcc (ou clang) -I chemin_dossier_autre/include -Lchemin_dossier_autre/lib (mais attention L et chemin doivent être collés ) mon_programme.c -lgmp ( les appels aux librairies génériques son l et le nom du paquet gmp ici ) -o mon_programme.

L'exécutable c étant mon_programme.

Avant tout il faut, comme indiqué au début, au début de chaque appel shell du programme, initialiser DYLD_LIBRARY_PATH par :
export DYLD_LIBRARY_PATH=chemin_dossier_autre/lib:${DYLD_LIBRARY_PATH}.

puis on exécute le programme
./mon_programme argument_1 argument_2 etc

Voila voila…un mois de recherche mais cela valait la peine.

Hélas il reste une inconnue : Apple a introduit depuis El Capitan une sécurité supplémentaire, le SIP.
Bien sur on peut le désactiver mais les utilisateurs de mon script ne ferons jamais cette manip.
Et il semble, dans cette configuration, mais cela reste à confirmer, qu'il y aurait alors des difficultés avec l'initialisation de DYLD_LIBRARY_PATH.
Ce serait bien ennuyeux car alors je ne verrai guère d'autres solution que l'installation pure et simple de gmp avec brew : mais il semble que tout ce qui est destiné à usr/local soit épargné : croisons les doigts.
Si tu as des idées là-dessus je suis preneur !

Et encore merci à toi !

[PBELL]

Bonjour,

mais il semble que tout ce qui est destiné à usr/local soit épargné : croisons les doigts.

Effectivement tout ce que j'ai trouvé sur SIP confirme que /usr est bien protégé, à l'exception de /usr/local.
Donc tu devrais être sauvé.

Il reste cependant que les Mac de tes amis bloqueront ton application car elle n'est pas signée.
Selon leur niveau de protection (Préférences/Sécurité/Général/Autorisez les application téléchargées....), soit l'application sera bloquée, soit il auront un message demandant leur accord explicite à la première utilisation.
Mieux vaut les prévenir.

Cordialement

[orthomimi]

Merci de ces précieux renseignements.

Pour l'ouverture ils ont déjà un mode d'emploi du genre : ctrl-clic sur l'application > ouvrir dans menu > ouvrir dans fenêtre.
En principe cela semble éviter d'aller modifier les préférences de sécurité qui, je crois, obligent plus ou moins a passer par le Terminal ( moi c'est ce que j'avais fait pour ma machine qui fonctionne avec des moyens obsolètes : Yosemite et maintenant Sierra et High Sierra, )
Mais je rame sur mes deux macBook pro de 2012...

Je ne sais pas si cette méthode marche aussi sur Catalina où le renforcement des sécurités prend des allures de goulag pour les amateurs de développement indépendant. De toutes façons je ne peux pas installer ce système sur mes vieilles machines !

Eh puis j'ai un autre souci c'est que je ne me sers ni de Xcode auquel je ne comprends rien du tout, ni de toutes les aides type Codeblock : en pratique c'est ScriptDebugger ancienne version pour l'AS et l'indispensable Sublime Text qui permet de programmer le C, le bash, Python aussi ( pas terrible par contre pour Applescript ).

Ce qui fait que, souvent, je ne saisis pas les méthodes indiquées dans les forums mac : je fréquente en fait, plutôt ceux de Linux qui sont nettement plus compréhensibles pour moi car c'est du bon vieil Unix : et c'est ce qui me plait tant dans l'AppleScript qui est un Unix vrai déguisé en femme du monde !!!

Evidemment j'use et abuse du terminal ( mais ni Vi ni les équivalents, que je ne connais pas non plus ).

Pour les "vieux", dont je fais hélas partie, cela change vraiment vite, trop vite, mais bien heureusement, une fois l'écume du flux retombée, on en revient quand même aux fondamentaux de programmation, et c'est heureux.

J'ai même lu récemment que le C était en train de redevenir très mode, d'après en tous cas, le concepteur de Linux.

Bon après ces propos philosophiques je retourne à mes programmes !

Cordialement

[PBELL]

Pour les "vieux", dont je fais hélas partie, cela change vraiment vite, trop vite, mais bien heureusement, une fois l'écume du flux retombée, on en revient quand même aux fondamentaux de programmation, et c'est heureux.

2000% d'accord !

Etant probablement encore plus vieux, je vais attendre et peut être verrai-je le retour du Pascal UCSD
En 1980, il fonctionnait déjà sur Apple II, Goupil et autres avec une machine virtuelle et des blocks applicatifs convertibles d'une plateforme à l'autre en quelques clicks (pardon, en quelques instructions !).
En 1982, j'ai ainsi converti environ 40000 lignes de Pascal d'Apple II vers Goupil, vers CMP, puis DOS et enfin Lisa, en moins de 15 jours !
40 ans plus tard, les nouveaux rois du monde découvrent les dockers et containers. C'est le cycle de la vie.

J'arrête, je deviens vieux .... et ronchon !