A ce rythme, pense à mettre un numéro de version sur ton soft
Je viens de te mettre la 1.1.3 en ligne. :P
dans 1235506462:
J'ai ouvert Clang GUI, il avait gardé en mémoire le dernier projet que j'ai analysé, un projet OSX. Du coup le menu combo en bas était grisé. J'ai fait glisser un projet iPhone à la place... le menu déroulant en bas ne s'est pas dégrisé. J'ai dû quitter Clang GUI et le relancer pour que le menu soit dispo... j'imagine que tu ne fais le test qu'une fois, à l'ouverture de ton app, et non à chaque fois qu'on fait glisser un nouveau projet ?
Je scanne dès qu'on charge un nouveau projet. T'as pas fais un Pomme+O par hasard? J'avais oublié de reporter le scan du fichier xcode pour détecter le type de projet. C'est corrigé.
dans 1235506462:
Sinon une fois que j'ai pu choisir le SDK, la build du projet iPhone a bien fonctionné (L'idéal serait de détecter le SDK utilisé pour le projet, qui doit sans doute être stocké qqpart dans le xcodeproj, mais bon)
Je n'ai pas vu cette info à première vue mais c'est un peu le bazard pour s'y retrouver dans leur fichier project.pbxproj à l'interieur du package xcodeproj.
dans 1235506462:
Ensuite comme il m'avait détecté des erreurs (cf plus bas, bien ce clang) je les ai corrigées... il m'a dit "a pu d'erreurs", mais dans l'onglet "Result" en effet la webView contenait encore l'ancien rapport ! Faudrait la vider à chaque relance de "Run" :P
Ca y est oui, j'ai compris. Je corrige ça.
dans 1235506462:
Après, le bouton "Run" mis par défaut (activable par la touche Entrée quoi) voire même un menuitem "Run" dans le nouveau menu Fichier avec le raccourci Pomme-R ou Pomme-B associé, serait idéal pour parfaire la chose...
- Bouton Run Ok. - Touche Enter Ok. - Raccourci Pomme-R Ok. J'ai aussi ajouté la sélection du répertoire du dernier projet pour le Pomme-O au passage.
Téléchargeable au même endroit (j'ai la flemme de gérer un historique... ).
Bon bein ça commence à ressembler à quelque chose tout ça....
dans 1235506462:
Sinon bien ce petit clang : il m'a détecté des erreurs comme quoi j'avais oublié de releaser dans le dealloc une variable d'instance déclarée comme @property(retain)... Or en effet dans dealloc j'ai pas [tt][monivar release];[/tt] mais j'ai mis comme à mon habitude [tt]monivar = nil;[/tt]... donc je pensais qu'il avait pas tilté et que c'était une fausse alerte... jusqu'à ce que je réalise que je n'avais pas mis le "self." devant... donc en écrivant comme ça en effet il n'appelle pas le setter ! En mettant [tt]self.monivar = nil[/tt], hop, bug disparu Merci clang !
Bon, comme ça commence à être presque parfait, faut quand même trouver des défauts encore, juste pour t'embêter... Tu vas voir, ils sont de haut niveau en plus.
- Dans la view où on fait le drag&drop du projet... finalement on a toujours une icône de projet Xcode du coup (à part au premier lancement où on n'a rien du tout). Quitte à mettre une icône, ça serait pas plus sympa de mettre, si elle est disponible, l'icône utilisée par l'application compilée ? (Icon.png par défaut, si cette valeur n'est pas écrasée par un autre nom de fichier pour l'icône dans le Info.plist du projet) ? Bon c'est p'tet un peu de fouillage pour pas grand chose j'avoue, à toi de voir
- Un double-clic dans cette vue pour ouvrir le projet dans Xcode serait sympa. Ainsi quand on vérifie nos projets, qui ne sont pas forcément ouverts, s'il nous détecte une erreur on peut toute de suite aller dans le projet pour corriger les problèmes dans les fichiers dans Xcode... Bon ok là c'est parce que je teste clang avec plusieurs de mes vieux projets existants, en pratique on l'utilise plutôt sur le projet qu'on a en cours donc souvent déjà ouvert dans Xcode, mais bon, ça mange pas de pain.
Ah et j'ai l'impression que dans cette version tu as pensé à vider la WebView "Result", mais pas son historique, du moins les flèches "<" et ">" au dessus de la WebView sont toujours là et actives comme si la WebView contenait encore l'ancien résultat (j'avais avant lu le rapport, cliqué sur un lien donc j'avais du coup "<" qui s'était activé... en relançant le build sur le projet corrigé, plus d'erreur, donc plus de rapport non plus... mais "<" toujours actif et quand je clique dessus il se grise et ">" devient actif, même si la WebView reste vide) D'ailleurs ça serait plus user-friendly que tu prévoies une page HTML (en interne à ton appli hein) à afficher quand y'a pas d'erreur, plutôt que de laisser la WebView vide, genre "Your project seems to be OK, no build error detected." pour rassurer l'utilisateur quoi.
Voilà , sinon, je pense que tu mérites ta tournée :PÂ <br /> PS : très bon les marshmallows dans la tasse de chocolat chaud sur ton icône (au début j'ai presque cru que c'était des glaçons, tu m'as fait peur )
Je viens de mettre en ligne une 1.1.4: - Gestion du double clique pour ouvrir le projet. - Ajout d'un menu contextuel au passage sur l'image pour ouvrir le projet ou son répertoire ("Open with finder" et "Reveal in Finder" comme dans Xcode). - Vidage de l'historique. - Ajout d'une boite de dialogue pour dire s'il n'y a pas d'erreur en attendant mieux.
Pour l'icone, faut voir, je suis pas convaincu. On visualise le projet, pas son application à proprement parlé. Mais bon pourquoi pas?
dans 1235521536:
Voilà , sinon, je pense que tu mérites ta tournée :P <br />
A tout de même! :P Je trouvais qu'il commençait à faire soif sur ce forums! ;D
dans 1235521536:
PS : très bon les marshmallows dans la tasse de chocolat chaud sur ton icône (au début j'ai presque cru que c'était des glaçons, tu m'as fait peur )
Bah si tu veux qu'on te donne un peu plus de boulot, plutôt que juste l'icône du fichier xcodeproj qui est tout le temps la même pour chaque projet Xcode, et plutôt que l'icône de l'application car c'est vrai que ce n'est pas l'application qu'on visualise mais le projet... Pourquoi pas un mix des deux ? L'icône d'un projet xcode + l'icône de l'application incrustée en bas à droite de l'icône du projet ? Ah ah, fallait pas chipoter si tu voulais pas du taf en plus hein ^^
Bah si tu veux qu'on te donne un peu plus de boulot, plutôt que juste l'icône du fichier xcodeproj qui est tout le temps la même pour chaque projet Xcode, et plutôt que l'icône de l'application car c'est vrai que ce n'est pas l'application qu'on visualise mais le projet... Pourquoi pas un mix des deux ? L'icône d'un projet xcode + l'icône de l'application incrustée en bas à droite de l'icône du projet ? Ah ah, fallait pas chipoter si tu voulais pas du taf en plus hein ^^
Il y a un besoin pour reconnaà®tre le projet en cours : icone ou simple nom , à toi de voir ...
En testant le mini-projet de Hillegass Image Fun chapitre 18, confirmation setImage est sensé faire un retain, alors que Hillegass le fait d'une manière exotique (il release l'ancienne image,sans faire de retain sur la nouvelle).
Il y a un besoin pour reconnaà®tre le projet en cours : icone ou simple nom , à toi de voir ...
Tu as le nom du projet juste au dessus de la zone de dépose.
Côté productivité, je viens d'ajouter un bouton pour ouvrir le fichier incriminé avec l'éditeur de texte par défaut lorsqu'on visualise une erreur. Après, un simple Pomme-L dans Xcode suivit du numéro de ligne permet d'aller rapidement à l'erreur. J'ai aussi ajouté le chemin du fichier en entête de WebView.
Un petit up pour une petite demande si je puis me permettre... et si c'est réalisable
Cela fait plusieurs fois que j'essaye (parce que ça me paraà®trait logique que ça marche dans la logique Mac quoi) de faire un drag&drop de l'icône de mon projet qui est tout en haut dans la colonne "Groups & Files" de Xcode pour la déposer dans ClangGUI... et qu'il aime pas.
Un petit up vu que je viens d'installer ClangGUI sur un nouveau poste qui me sert de poste de dev. J'ai vu que depuis il y avait eu une nouvelle version sur ton site que je n'avais donc pas vue
Cependant 2 petits artefacts pas bien méchants mais vite énervants :
1) Quand la compilation foire (build failed, N errors), du coup il n'y a pas de rapport créé par clang... et ton appli dit "Congratulations, no errors found"... ça fait pas très propre et cohérent... surtout que justement je me suis fait avoir (j'ai pensé que mon code était correct et que clang l'avait analysé comme sans faute manifeste... alors qu'au contraire il ne compilait pas, je m'en suis rendu compte dans Xcode juste après)
2) Toujours pas moyen de faire glisser l'icône/ligne représentant le projet de la zone "Groups & Files" dans Xcode vers ton appli Obligé de faire glisser le vrai fichier... pourtant en tant que MacUser j'ai plus d'une fois été tenté (et essayé) de faire un drag&drop de cette première ligne de panneau "Groups & Files"... et à chaque fois je me fais avoirÂ
Et par contre un gros problème : Je viens de tester ClangGUI avec mon premier programme iPhone utilisant le SDK 3.0, et même si le code compile parfaitement dans Xcode, ClangGUI ne semble pas le compiler, lui : dans tes logs, en réponse à la commande "ccc-analyzer", il me met des trucs comme :
In file included from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:30, from /Users/olivier/Documents/Dev iPhone/GKSession/GKSession_Prefix.pch:7, from <command line>:1: /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UILocalizedIndexedCollation.h:11: error: syntax error before 'AT_NAME' token /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UILocalizedIndexedCollation.h:19: error: syntax error before '}' token /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UILocalizedIndexedCollation.h:21: fatal error: method definition not in @implementation context compilation terminated. {standard input}:32:FATAL:.abort detected. Assembly stopping. ** BUILD FAILED **
Et à la fin de ton log du coup il me met
CompileC build/GKSession.build/Release-iphonesimulator/GKSession.build/Objects-normal/i386/GKSessionAppDelegate.o "/Users/olivier/Documents/Dev iPhone/GKSession/Classes/GKSessionAppDelegate.m" normal i386 objective-c com.apple.compilers.gcc.4_2
et ce pour les 3 fichiers qu'il a essayé de compiler et pour lesquels il m'a mis le "BUILD FAILED" mentionné au dessus.
J'ai bien choisi "iPhoneSimulator3.0.sdk" dans le menu dropdown en bas de la fenêtre pourtant. D'ailleurs c'est normal qu'on n'ait que les SDK "Simulator" dans ce dropdown, et pas les variantes "Device" ? (à priori c'est les mêmes SDK et headers à la base, mais bon me dit que justement ça vient p'tet aussi de là , et de méthodes implémentées dans le device mais pas le simulateur ou quoi...?)
Tatouille, du forum de Mac Gé, travaille sur une nouvelle version.
Pour répondre à tes questions dans l'ordre: 1) effectivement, en l'état il faut que le projet compile correctement. Je vais lui faire passer l'info. 2) je lui ai déjà remonté ta remarque. Le problème vient plus d'Xcode en fait. Si tu drag&drop ton icône sur une fenêtre du terminal tu verras qu'en fait ce n'est pas le chemin du projet qu'on obtient mais celui du répertoire du projet. Du coup, en l'état cela ne fonctionne pas. 3) Pour ton problème avec le SDK 3.0 c'est vraisemblablement un problème de compatibilité. Ce que je te propose en attendant une MAJ c'est de télécharger les derniers binaires de Clang (http://checker.minormatter.com/checker-0.209.tar.bz2). Ensuite, dans les ressources du package de Clang Gui tu as un répertoire 'clang' qui contient les binaires. Avec un peu de chance, la dernière version est compatible avec la beta du sdk. Si ça ne marche pas, il faudra patienter un peu que pour que le projet LLVM/Clang le prenne en compte.
PS: L'analyseur de Clang n'est pas compatible avec une compilation pour ARM (du moins à ma connaissance pour le moment). Du coup effectivement, sur un projet iPhone on ne peut utiliser que le mode émulateur.
Je viens de tester ClangGui sur mon projet iPhone.
Sur l'iPhone OS 3.0, il ne me trouvait pas de bug mémoire. Il en a trouvé 3 sur l'OS 2.2.1, leaks que je viens de corriger... bizarre.
Ah tiens, il n'arrivait pas à compiler à nouveau en 2.2.1 mais il vient de me trouver un bug qu'xCode ne signaler pas : 2 fois le même objet dans @synthesize !
Là , il compile pour toutes les versions de l'OS avec succès. Très bon outil, je confirme. Merci Mala !
J'ai voulu testé mon application, qui marche très bien mais qui, je dois l'avouer, est absolument abominable niveau mémoire. Je comptais utiliser Clang pour m'aider à gérer la mémoire.
J'ai été surpris, car il me disait pas d'erreur. N'y croyant pas, je regarde le rapport, et j'obtiens ce que j'ai mis en pièce-jointe de ce message.
Le projet compile parfaitement bien sous Xcode (pas d'erreur, pas de warning) mais pas lorsque je passe par Clang UI. Il n'arrive pas à compiler un fichier de Xcode.
Il semble que ce soit un problème de version de compilateur. Le gcc 4.0 ne marcherait pas, alors que ca marche avec le gcc 4.2 Il faudrait que Clang utilise le même compilateur utilisé par défaut par Xcode.
Alors, j'ai changé le compilateur sous Xcode dans la fenetre "project settings".
Lorsque j'etais sous gcc4.2 il n'y avait aucune erreur ni warning. Sous gcc4.0, il apparait les mêmes erreurs que sous Clang.
Voilà . J'ai pas le niveau pour coder de manière à ce que toutes les versions du compilateur fonctionnent. Je me cantonne à la version 4.2 Donc ça sera cool pour les débutants, comme moi, (surtout que ce soft est aussi destiné aux débutants) si le compilateur utilisé était celui du projet.
Ou du moins, pouvoir choisir le compilateur de notre choix.
PS: que ça soit moi ou pas, l'erreur viens d'un header de UIKit...
En même temps Clang utilise des technologies de la LLVM de gcc il me semble, qui n'est apparue que dans les dernières versions dudit gcc (je sais plus à partir de laquelle). Donc pas dit que ça soit possible de demander à Clang d'utiliser un gcc plus ancien.
Je ne demande pas à Clang d'utiliser une version plus ancienne, j'aimerai qu'il utilise une version plus récente !
Il utilise gcc4.0 alors que j'utilise gcc4.2 dans mon projet. Sous Xcode, gcc4.2 compile bien le projet mais pas gcc4.0. gcc4.0 me met les mêmes erreurs que Clang.
Je comprend pas pourquoi il veut pas utiliser gcc4.2... un problème dans mes bin peut-etre ?
Alors faudrait demander à l'auteur de ClangGUI, mais en fait il a si je ne m'abuse intégré le binaire de gcc directement dans le bundle de ClangGUI, parce qu'il a pris une version spéciale (justement gcc-llvm) qui n'est pas la version fournie avec les DevTools je crois, enfin ça doit être un truc comme ça.
Après, existe-t-il gcc-llvm en version 4.2 qui pourrait permettre de supporter Clang...? A priori oui puisque la prochaine version de Xcode avec SnowLeo intégrera directement Clang (avec les bubbles et tout affichées dans Xcode là où y'a des erreurs détectées par Clang), donc c'est que c'est déjà dans les bacs (ou alors très avancé)...
Mais bon en attendant faut p'tet la récupérer voire la compiler from sources car c'est p'tet pas la même (à cause du module LLVM) que celle fournie avec les DevTools et Xcode 3.1.3 ?
Enfin je dis ça je dis peut-être une grosse connerie, j'avoue que je me perds facilement entre LLVM, Clang et tout et quelle version de gcc est actuellement fournie et tout. Je dis juste tout ça "de mémoire" vaguement quoi :P
Oui, vivement SnowLeo et surtout la dernière version de Xcode qui va avec En fait c'est pas des bulles comme on les connaà®t : d'après ce qu'ils expliquaient à la WWDC* : - on lance le mode "Build and Analyze" - ça génère des petites infos au niveau des lignes (bon en fait c'est des bulles sauf que dans le nouveau Xcode ils les présentent d'une autre manière, plus lisible et moins gênantes pour la lecture du code qd elles sont affichées) - ça rajoute aussi des flèches pour indiquer le chemin pris au moment de l'analyse
Bref, il promet ce futur Xcode En tout cas pour l'instant faut se contenter de Clang... et de la version fournie dans ClangGUI. Ou alors (vu que le projet clang.llvm.org a l'air bien actif) aller chercher la dernière version de scan-build et l'utiliser en ligne de commande. Après tout c'est pas si sorcier semble-t-il
* C'est dans la session 401 pour ceux qui les ont achetées sur l'iTunes Store : "Improving your application with the Xcode Static Analyser"
Après faut voir les paramètres à passer à la commande xcodebuild (autrement dit les paramètres que de toute façon tu passerais à la commande xcodebuild si tu voulais compiler ton projet en ligne de commande ; utiliser Clang consiste juste en gros à rajouter "scan-build" devant cette ligne de commande de compilation du projet)
En théorie si vu Xcode Analyzer (clang) n'est que sur Xcode 3.2 utilisable seulement sur Snow Leopard, tout deux dispo seulement pour les ADC payant (hors student) ou pour les personnes présentent à la WWDC, dans les deuc cas sous NDA ^^
Je dirais même que tout le oueb le sait, et une moitié du web l'utilise déjà vu qu'il ne faut pas être un surdoué de l'informatique pour trouver une image de snow...
Donc NDA ou pas, ceux qui ont obtenu Snow Leopard illégalement peuvent se "permettre" de balancer plein d'infos sans rien risquer.
Réponses
Je viens de te mettre la 1.1.3 en ligne. :P
Je scanne dès qu'on charge un nouveau projet. T'as pas fais un Pomme+O par hasard? J'avais oublié de reporter le scan du fichier xcode pour détecter le type de projet. C'est corrigé.
Je n'ai pas vu cette info à première vue mais c'est un peu le bazard pour s'y retrouver dans leur fichier project.pbxproj à l'interieur du package xcodeproj.
Ca y est oui, j'ai compris. Je corrige ça.
- Bouton Run Ok.
- Touche Enter Ok.
- Raccourci Pomme-R Ok.
J'ai aussi ajouté la sélection du répertoire du dernier projet pour le Pomme-O au passage.
Téléchargeable au même endroit (j'ai la flemme de gérer un historique...
Bon bein ça commence à ressembler à quelque chose tout ça....
Oui c'est sympa hein!
- Dans la view où on fait le drag&drop du projet... finalement on a toujours une icône de projet Xcode du coup (à part au premier lancement où on n'a rien du tout). Quitte à mettre une icône, ça serait pas plus sympa de mettre, si elle est disponible, l'icône utilisée par l'application compilée ? (Icon.png par défaut, si cette valeur n'est pas écrasée par un autre nom de fichier pour l'icône dans le Info.plist du projet) ? Bon c'est p'tet un peu de fouillage pour pas grand chose j'avoue, à toi de voir
- Un double-clic dans cette vue pour ouvrir le projet dans Xcode serait sympa. Ainsi quand on vérifie nos projets, qui ne sont pas forcément ouverts, s'il nous détecte une erreur on peut toute de suite aller dans le projet pour corriger les problèmes dans les fichiers dans Xcode... Bon ok là c'est parce que je teste clang avec plusieurs de mes vieux projets existants, en pratique on l'utilise plutôt sur le projet qu'on a en cours donc souvent déjà ouvert dans Xcode, mais bon, ça mange pas de pain.
Ah et j'ai l'impression que dans cette version tu as pensé à vider la WebView "Result", mais pas son historique, du moins les flèches "<" et ">" au dessus de la WebView sont toujours là et actives comme si la WebView contenait encore l'ancien résultat (j'avais avant lu le rapport, cliqué sur un lien donc j'avais du coup "<" qui s'était activé... en relançant le build sur le projet corrigé, plus d'erreur, donc plus de rapport non plus... mais "<" toujours actif et quand je clique dessus il se grise et ">" devient actif, même si la WebView reste vide)
D'ailleurs ça serait plus user-friendly que tu prévoies une page HTML (en interne à ton appli hein) à afficher quand y'a pas d'erreur, plutôt que de laisser la WebView vide, genre "Your project seems to be OK, no build error detected." pour rassurer l'utilisateur quoi.
Voilà , sinon, je pense que tu mérites ta tournée :PÂ
PS : très bon les marshmallows dans la tasse de chocolat chaud sur ton icône (au début j'ai presque cru que c'était des glaçons, tu m'as fait peur
- Gestion du double clique pour ouvrir le projet.
- Ajout d'un menu contextuel au passage sur l'image pour ouvrir le projet ou son répertoire ("Open with finder" et "Reveal in Finder" comme dans Xcode).
- Vidage de l'historique.
- Ajout d'une boite de dialogue pour dire s'il n'y a pas d'erreur en attendant mieux.
Pour l'icone, faut voir, je suis pas convaincu. On visualise le projet, pas son application à proprement parlé. Mais bon pourquoi pas?
A tout de même! :P Je trouvais qu'il commençait à faire soif sur ce forums! ;D
C'est l'icône des templates d'Xcode.
Il y a un besoin pour reconnaà®tre le projet en cours : icone ou simple nom , à toi de voir ...
Autrement quelqu'un a-t-il eu le temps de tester/valider mon test sur Clang ?
En testant le mini-projet de Hillegass Image Fun chapitre 18, confirmation setImage est sensé faire un retain, alors que Hillegass le fait d'une manière exotique (il release l'ancienne image,sans faire de retain sur la nouvelle).
Tu as le nom du projet juste au dessus de la zone de dépose.
Côté productivité, je viens d'ajouter un bouton pour ouvrir le fichier incriminé avec l'éditeur de texte par défaut lorsqu'on visualise une erreur. Après, un simple Pomme-L dans Xcode suivit du numéro de ligne permet d'aller rapidement à l'erreur. J'ai aussi ajouté le chemin du fichier en entête de WebView.
Un petit up pour une petite demande si je puis me permettre... et si c'est réalisable
Cela fait plusieurs fois que j'essaye (parce que ça me paraà®trait logique que ça marche dans la logique Mac quoi) de faire un drag&drop de l'icône de mon projet qui est tout en haut dans la colonne "Groups & Files" de Xcode pour la déposer dans ClangGUI... et qu'il aime pas.
Jouable, pas jouable ?
Un petit up vu que je viens d'installer ClangGUI sur un nouveau poste qui me sert de poste de dev.
J'ai vu que depuis il y avait eu une nouvelle version sur ton site que je n'avais donc pas vue
Cependant 2 petits artefacts pas bien méchants mais vite énervants :
1) Quand la compilation foire (build failed, N errors), du coup il n'y a pas de rapport créé par clang... et ton appli dit "Congratulations, no errors found"... ça fait pas très propre et cohérent... surtout que justement je me suis fait avoir (j'ai pensé que mon code était correct et que clang l'avait analysé comme sans faute manifeste... alors qu'au contraire il ne compilait pas, je m'en suis rendu compte dans Xcode juste après)
2) Toujours pas moyen de faire glisser l'icône/ligne représentant le projet de la zone "Groups & Files" dans Xcode vers ton appli
Et par contre un gros problème : Je viens de tester ClangGUI avec mon premier programme iPhone utilisant le SDK 3.0, et même si le code compile parfaitement dans Xcode, ClangGUI ne semble pas le compiler, lui : dans tes logs, en réponse à la commande "ccc-analyzer", il me met des trucs comme : Et à la fin de ton log du coup il me met et ce pour les 3 fichiers qu'il a essayé de compiler et pour lesquels il m'a mis le "BUILD FAILED" mentionné au dessus.
J'ai bien choisi "iPhoneSimulator3.0.sdk" dans le menu dropdown en bas de la fenêtre pourtant.
D'ailleurs c'est normal qu'on n'ait que les SDK "Simulator" dans ce dropdown, et pas les variantes "Device" ? (à priori c'est les mêmes SDK et headers à la base, mais bon me dit que justement ça vient p'tet aussi de là , et de méthodes implémentées dans le device mais pas le simulateur ou quoi...?)
Pour répondre à tes questions dans l'ordre:
1) effectivement, en l'état il faut que le projet compile correctement. Je vais lui faire passer l'info.
2) je lui ai déjà remonté ta remarque. Le problème vient plus d'Xcode en fait. Si tu drag&drop ton icône sur une fenêtre du terminal tu verras qu'en fait ce n'est pas le chemin du projet qu'on obtient mais celui du répertoire du projet. Du coup, en l'état cela ne fonctionne pas.
3) Pour ton problème avec le SDK 3.0 c'est vraisemblablement un problème de compatibilité. Ce que je te propose en attendant une MAJ c'est de télécharger les derniers binaires de Clang (http://checker.minormatter.com/checker-0.209.tar.bz2). Ensuite, dans les ressources du package de Clang Gui tu as un répertoire 'clang' qui contient les binaires. Avec un peu de chance, la dernière version est compatible avec la beta du sdk. Si ça ne marche pas, il faudra patienter un peu que pour que le projet LLVM/Clang le prenne en compte.
PS: L'analyseur de Clang n'est pas compatible avec une compilation pour ARM (du moins à ma connaissance pour le moment). Du coup effectivement, sur un projet iPhone on ne peut utiliser que le mode émulateur.
Sur l'iPhone OS 3.0, il ne me trouvait pas de bug mémoire.
Il en a trouvé 3 sur l'OS 2.2.1, leaks que je viens de corriger... bizarre.
Ah tiens, il n'arrivait pas à compiler à nouveau en 2.2.1 mais il vient de me trouver un bug qu'xCode ne signaler pas : 2 fois le même objet dans @synthesize !
Là , il compile pour toutes les versions de l'OS avec succès. Très bon outil, je confirme. Merci Mala !
J'ai voulu testé mon application, qui marche très bien mais qui, je dois l'avouer, est absolument abominable niveau mémoire.
Je comptais utiliser Clang pour m'aider à gérer la mémoire.
J'ai été surpris, car il me disait pas d'erreur.
N'y croyant pas, je regarde le rapport, et j'obtiens ce que j'ai mis en pièce-jointe de ce message.
Le projet compile parfaitement bien sous Xcode (pas d'erreur, pas de warning) mais pas lorsque je passe par Clang UI. Il n'arrive pas à compiler un fichier de Xcode.
Voilà pour ma contribution.
Adrien
http://www.iphonedevsdk.com/forum/iphone-sdk-development/18567-some-problem-os-3-0-compatibility.html
http://stackoverflow.com/questions/1078001/clang-giving-errors-complaining-about-defective-header-file-uilocalizedindexedcol
Trouvée là :
http://www.google.com/search?client=safari&rls=fr-fr&q=UILocalizedIndexedCollation&ie=UTF-8&oe=UTF-8
Il semble que ce soit un problème de version de compilateur. Le gcc 4.0 ne marcherait pas, alors que ca marche avec le gcc 4.2
Il faudrait que Clang utilise le même compilateur utilisé par défaut par Xcode.
Enfin je crois...
Lorsque j'etais sous gcc4.2 il n'y avait aucune erreur ni warning.
Sous gcc4.0, il apparait les mêmes erreurs que sous Clang.
Voilà .
J'ai pas le niveau pour coder de manière à ce que toutes les versions du compilateur fonctionnent. Je me cantonne à la version 4.2
Donc ça sera cool pour les débutants, comme moi, (surtout que ce soft est aussi destiné aux débutants) si le compilateur utilisé était celui du projet.
Ou du moins, pouvoir choisir le compilateur de notre choix.
PS: que ça soit moi ou pas, l'erreur viens d'un header de UIKit...
Tu as bien lu la Doc de Clang?
Je vous met le code source pour que vous puissiez tester, au cas où.
Dommage, j'aimerai vraiment pouvoir utiliser cet outil avec l'interface graphique.
Il utilise gcc4.0 alors que j'utilise gcc4.2 dans mon projet.
Sous Xcode, gcc4.2 compile bien le projet mais pas gcc4.0. gcc4.0 me met les mêmes erreurs que Clang.
Je comprend pas pourquoi il veut pas utiliser gcc4.2... un problème dans mes bin peut-etre ?
Après, existe-t-il gcc-llvm en version 4.2 qui pourrait permettre de supporter Clang...? A priori oui puisque la prochaine version de Xcode avec SnowLeo intégrera directement Clang (avec les bubbles et tout affichées dans Xcode là où y'a des erreurs détectées par Clang), donc c'est que c'est déjà dans les bacs (ou alors très avancé)...
Mais bon en attendant faut p'tet la récupérer voire la compiler from sources car c'est p'tet pas la même (à cause du module LLVM) que celle fournie avec les DevTools et Xcode 3.1.3 ?
Enfin je dis ça je dis peut-être une grosse connerie, j'avoue que je me perds facilement entre LLVM, Clang et tout et quelle version de gcc est actuellement fournie et tout. Je dis juste tout ça "de mémoire" vaguement quoi :P
Tout est là dans les commentaires:
http://www.fruitstandsoftware.com/blog/index.php/2008/08/finding-memory-leaks-with-the-llvmclang-static-analyzer/
Bon, je vais attendre alors...
En fait c'est pas des bulles comme on les connaà®t : d'après ce qu'ils expliquaient à la WWDC* :
- on lance le mode "Build and Analyze"
- ça génère des petites infos au niveau des lignes (bon en fait c'est des bulles sauf que dans le nouveau Xcode ils les présentent d'une autre manière, plus lisible et moins gênantes pour la lecture du code qd elles sont affichées)
- ça rajoute aussi des flèches pour indiquer le chemin pris au moment de l'analyse
Bref, il promet ce futur Xcode
En tout cas pour l'instant faut se contenter de Clang... et de la version fournie dans ClangGUI. Ou alors (vu que le projet clang.llvm.org a l'air bien actif) aller chercher la dernière version de scan-build et l'utiliser en ligne de commande. Après tout c'est pas si sorcier semble-t-il
* C'est dans la session 401 pour ceux qui les ont achetées sur l'iTunes Store : "Improving your application with the Xcode Static Analyser"
Ensuite pour l'utiliser depuis le terminal c'est pas bien méchant : http://clang-analyzer.llvm.org/scan-build.html
Après faut voir les paramètres à passer à la commande xcodebuild (autrement dit les paramètres que de toute façon tu passerais à la commande xcodebuild si tu voulais compiler ton projet en ligne de commande ; utiliser Clang consiste juste en gros à rajouter "scan-build" devant cette ligne de commande de compilation du projet)
ps: Ya pas de NDA sur Xcode?
En théorie si vu Xcode Analyzer (clang) n'est que sur Xcode 3.2 utilisable seulement sur Snow Leopard, tout deux dispo seulement pour les ADC payant (hors student) ou pour les personnes présentent à la WWDC, dans les deuc cas sous NDA ^^
Mais bon tout le oueb le sait :-°
En tout cas c'est très pratique comme fonction ^^
Je dirais même que tout le oueb le sait, et une moitié du web l'utilise déjà vu qu'il ne faut pas être un surdoué de l'informatique pour trouver une image de snow...
Donc NDA ou pas, ceux qui ont obtenu Snow Leopard illégalement peuvent se "permettre" de balancer plein d'infos sans rien risquer.