Débugger une appli compilée en "deployement" c'est possible ça ?
ClicCool
Membre
Bonjour,
en fait le titre est ici un peu trompeur.
Je ne cherche pas à débugger une appli compilée en mode deployement.
Mais par contre je m'étonne que je puisse lancer "build and Debug" quand l'active build configuration est réglée sur "Deployement" sans avoir le moindre message m'avertissant que mes points d'arrêt seront inopérants.
En effet, de temps à autres, je sort une mouture en "deployement" histoire de faire tourner mes àŸétas alors même que je poursuit le codage et débuggage du projet.
Le soucis c'est que régulièrement j'oublie de re-positionner l'active target sur "Development".
Hier encore c'est ce qui est arrivé.
Je place un Break Point dans une méthode de gestion des erreurs, je Build and Debug et j'ai l'impression de ma méthode n'est jamais appelée ...
... Il m'a fallu plus de 24h avant que je me rende compte que j'avais pas re-basculé sur "Development" !!!
Je tombe régulièrement sur ce piège et j'aurais aimé être alerté par xCode dans ces cas là !
Voire même que xCode désactive carrément le Build an Debug chaque fois qu'on est en Deployment.
A moins qu'il soit possible de débugger en Deployment ?
D'où le titre du Thread.
en fait le titre est ici un peu trompeur.
Je ne cherche pas à débugger une appli compilée en mode deployement.
Mais par contre je m'étonne que je puisse lancer "build and Debug" quand l'active build configuration est réglée sur "Deployement" sans avoir le moindre message m'avertissant que mes points d'arrêt seront inopérants.
En effet, de temps à autres, je sort une mouture en "deployement" histoire de faire tourner mes àŸétas alors même que je poursuit le codage et débuggage du projet.
Le soucis c'est que régulièrement j'oublie de re-positionner l'active target sur "Development".
Hier encore c'est ce qui est arrivé.
Je place un Break Point dans une méthode de gestion des erreurs, je Build and Debug et j'ai l'impression de ma méthode n'est jamais appelée ...
... Il m'a fallu plus de 24h avant que je me rende compte que j'avais pas re-basculé sur "Development" !!!
Je tombe régulièrement sur ce piège et j'aurais aimé être alerté par xCode dans ces cas là !
Voire même que xCode désactive carrément le Build an Debug chaque fois qu'on est en Deployment.
A moins qu'il soit possible de débugger en Deployment ?
D'où le titre du Thread.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Désolé, je n'apporte pas de réponse, mais je signale que j'ai le même problème !
+
Chacha
Merci Chacha,
Je me sens moins seul tout d'un coup
Ben on est 3 au club ... pour l'instant.
Y'en a pas d'autres ?
L'Option "Build and Debug" a-t-elle un sens dans le mode Deployment ?
Parse que si la réponse est non, pourquoi diable laisser la possibilité de l'utiliser ?
Ca ressemble alors fort à un Bug de conception/interface ce truc là !
Stricto sensu, le mode "Deployment" ou "Development" ne sont que des "Build Configuration", c'est à dire des... configurations, des sortes de "sets" regroupant des réglages de compilation.
Par exemple, par défaut Xcode crée les 2 build configuration les plus usuelles et pratiques, une spécialisée dans le "Debug", pour laquelle les réglages de build indiquent qu'il faut générer les infos de débug dans le binaire généré, en particulier, et une spécialisée dans l'aspect "Release"/"Deployment", qui ne contient pas d'infos de debug, fait un link complet (au lieu du réglage zerolink de la config "Debug"), etc.
Mais on peut très bien créer autant de build configurations que l'on souhaite. Et dans ce cas, qu'est ce que vous attenderiez que Xcode fasse ? désactive les boutons de debug en fonction de quels critères ?
Ce que je veux dire c'est que même si dans 99% du temps on se contente de ces 2 configurations par défaut, rien ne les caractérise directement. On peut très bien modifier les réglages de la configuration "Release" pour faire en sorte qu'elle inclut les symboles de debug, et donc devienne débuggable ! ::)
Après ce que Xcode devrait faire mais semble ne pas faire, c'est nous prévenir quand on essaye de débuguer un binaire dans lequel les symboles de debug n'ont pas été généré, par contre. Mais pas de désactiver les boutons "Build & Debug" pour autant.
Enfin d'accord, bien sur, sur le fait que les noms des build styles ne sont pas LE facteur décisif, loin s'en faut.
Rien n'empèche, en effet, de configurer le mode appelé "Deployment" pour qu'il inclus les infos de débogage, ni même de configurer le mode appelé "Development" pour qu'il n'inclue pas ces infos et même fasse tous les liens nécessaires à une appli autonome.
Mais bon sang, quand les symboles de débug sont absents (quelque soit le nom porté par le style de build) pourquoi laissé actif l'option débug ?
Voire même, pourquoi ne pas alerter l'utilisateur en rappelant quelle option de configuration de build est manquante pour permettre un débogage efficace ?
C'est si compliqué que ça pour xCode de savoir si oui ou nom un débogage est possible en fonction de la configuration de build ?
Nous sommes en effet pleinement d'accord.
J'avais lu trop vite ton post en me laissant bêtement distraire par le travail en même temps :P
Tu te rends compte de ce que tu viens d'avouer là ? Mais c'est un crime, ça !
Je demande qu'on bannisse ClicCool d'OC pour ça. Sauf si.... sauf s'il offre sa tournée pour se rattraper
comment ça c'est encore une excuse bidon (fdeb pour les intimes :P) pour boire un coup ? Noooannn, du tout....
C'est bien la peine qu'Ali se retienne d'écrire des posts de trois kilomètres si on ne les lit pas attentivement
Etant donné que chez moi j'utilise le build setting nommé "Deployment" et que le résultat est alors placé dans le dossier "Deployment" d'où je l'extrait SYSTEMATIQUEMENT pour le placer avec mes autres applis.
Je pars du principe que si l'appli est lancée depuis le dossier "Deployment" c'est que j'ai encore lancé un Build and Debug en mode Deployment.
J'ai donc ajouté ça dans le Initialise de mon contrôleur:
Comme ça, en un coup d'oeil sur le log je suis fixé sur mon oubli sans attendre désespérément qu'un break-point se déclenche
Non mais c'est vraiment pas sérieux ... Va falloir une énorme tournée générale pour réparer tout ca ...
(le premier qui fait remarquer qu'il y a une faute dans mon post, je ne sais pas ce que j'en fais mais il a intérêt à bien se cacher)
Manque une cédille à ça ;D
Bien sûr pour que ça marche il faut aller dans les Build Settings (Project Info -> Build), et dans la collection "Preprocessing" tout en bas du menu déroulant, rajouter "DEBUG" dans le "Preprocessor Macros" de la configuration "Debug" (et pas dans la release du coup bien sûr)
La définition de cette macro, qui est pourtant bien pratique (par exemple pour faire des NSLog uniquement en mode debug, etc), n'est pas effectuée par défaut, et c'est bien dommage, mais bon, en modifiant les modèles de projet utilisés par Xcode (se trouvant dans "Application Support" je crois) on peut faire en sorte que tous les nouveaux projets aient cette macro définie en mode debug et pas en Release, pour générer du code conditionnel du genre :
Oui Ali, je connais bien cette possibilité des macros de Logs conditionnels, elle impose en effet quelques manips qui ne fonctionnent pas toujours comme voulu du reste ...
En fait c'est assez proche de "NS_BLOCK_ASSERTIONS=1"Â que l'on ajoute comme un "OTHER_CFLAGS" dans les customized settings du build façon Deployment afin de virer toutes les assertions de la version deployment.
Mais je vois pas trop où ça nous mème ici.
En effet ça vire les Logs et les Assertions dans la version deployment MAIS justement j'en ai alors besoin dans le cas d'une version Deployment lancée en mode débug.
LE pb ici n'est pas de ne permettre les logs qu'en mode Débug, ni de virer les assertions dans ces cas là !
Le pb est d'identifier un mode Deployment actif A TORD et donc de générer quand même un log (voire une alerte modale pour les plus étourdis, pourquoi pas), en partant du principe que l'appli compilée en Deployment n'a pas de raison d'être lancé à partir du dossier "deployment" du projet. (elle est censée prendre d'abord sa place avec les autres appli et dans ce cas là aucun log n'est fait)
(Le bout de code n'était qu'un exemple, là )
Oui oui,
Mais quel bout de code tu proposes pour alerter d'une complie faite à tord en style Deployment puis lancée en Build and Debug, de façon à ce que l'on attende pas inutilement le déclenchement d'un break-point ?
???
[EDIT] Bon, pour stimuler les imaginations j'offre la tournée à celui qui trouvera l'astuce la plus élégante
t'as qu'à faire attention, aussi
Bon je pense que j'ai une solution pas mal... et que je mérite la tournée.
Seul hic, c'est que ça marche dans le sens inverse de celui que j'espérais : ça fait un truc si on est en debug, rien si on débug pas. Mais bon, à mon avis ça va te plaire.
Bref, avec cette solution, à chaque fois qu'on débugue un programme avec Build & Debug, et que ce programme était compilé en Debug (Development), ben il prononcera "Breakpoints are active." au début de l'execution.
Mais si on lance le Debug d'une appli qu'on a compilé en Deployment/Release, il ne dira rien du tout !
Et vu qu'on a mis ça dans "Global Breakpoint", ben c'est "project-wide" !! Si on change de projet, le breakpoint est toujours mémorisé. On n'a pas à penser le placer à la main sur chacun de nos projets, puisque tel qu'on l'a défini ça veut dire "sur tous mes projets, dès que la fonction "main" est appelée, prononce ce texte... à partir du moment où tu prends en compte les breakpoints, ce qui n'est vrai qu'en mode débugage dans Xcode
Bon je suis d'accord, ça aurait été mieux dans le sens inverse, mais suis pas sûr que ce soit possible, et puis cette solution est élégante je trouve alors bon... :adios!:
[Fichier joint supprimé par l'administrateur]
Très intéressante ta solution.
Je t'avoue que je sous-utilise ces fonctions "avancées" des Break-Points et tu m'as donné envie d'aller y voir de plus près.
Rien que pour ça t'as droit à ta tournée, qu'est-ce que j'te sers ?
Ben oui ça me plait assez MAIS c'est l'inverse que je voudrais.
Speach ça passe bien pour un événement ponctuel qu'il faut pas louper, mais pas à chaque fois que je relance l'appli en débug, ça va vite me taper sur le système et suis pas sur qu'à la longue je me rende compte s'il le dit ou pas !
idem pour le log que je finirais par plus voir et dont l'absence sautera pas aux yeux au moment voulu.
Le concours est toujours ouvert donc ! ::)