›

Framework Metal not found

pistonman33pistonman33 Membre
dans API UIKit #1

Bonjour à  tous,


 


Je bloque sur un problème depuis quelque jours et j'avoue ne pas maitriser le sujet, j'essaye de faire une application qui tourne sous IOS7 et IOS8 avec cocoapods. Lorsque j'installe les dernières versions de librairies dans mon projet et que je les utilisent, je tombe sur des erreurs du genre Metal framework not found! Je sais que c'est uniquement disponible sous IOS8 mais je n'arrive pas à  comprendre comment gèrer ce problème d'édition de lien. Dans mon fichier PodFile je ne défini pas de platform ios.


 


Bien à  vous.


 


Réponses

  • CéroceCéroce Membre, Modérateur
    #2
    On pourrait voir le Podfile ?
    Sinon, as-tu vérifié dans les Build Settings que tu n'as pas la framework Metal ?
  • pistonman33pistonman33 Membre
    #3

    Mon PodFile est super simple:


     


    target 'StickersBeacon' do

    pod 'EstimoteSDK', '2.4.0'

    end


     


    J'ai commenté


     


    #post_install do |installer_representation|

    #    installer_representation.project.targets.each do |target|

    #        target.build_configurations.each do |config|

    #            config.build_settings = 'NO'

    #           config.build_settings = 'armv7 armv7s'

    #        end

    #    end

    #end


     


    Dans le Build Settings de Pods pas de Metal dedans.


    Je suppose que c'est bien dans Pods qu'il faut tout regarder car c'est lui qui prime sur celui de mon projet ?

  • AliGatorAliGator Membre, Modérateur
    #4
    Si tu veux que CocoaPods ne te récupère que les pods qui sont compatibles iOS7+ (et ne risque pas de te récupérer les librairies qui nécessitent iOS8 comme celles dépendant Metal) il faut que tu indiques dans ton Podfile la version iOS supportée*
     
    xcodeproj 'chemin/vers/ton/projet'
    
platform :ios, '7.0'
    

    
...
    Dans ce cas CocoaPods ne te récupèrera que les pods qui sont pour iOS7 et supérieur.
    (S'il te récupère un pod qui nécessite iOS8 / Metal malgré tout, c'est certainement que le pod en question a mal écrit son fichier podspec et a déclaré qu'il supportait iOS7 alors que ce n'est pas le cas)

    Pour plus d'infos, voir les liens dans ma signature, en particulier Le guide sur la syntaxe d'un Podfile.

    (*) Nous ne faisons pas encore de retro-engeneering sur le fichier XcodeProj pour récupérer cette version minimum depuis les settings de chaque target de ton projet, bien que ce soit une évolution à  laquelle on pense, mais pas prioritaire vu le boulot qu'on a déjà 
  • AliGatorAliGator Membre, Modérateur
    #5
    Quelle version de CocoaPods utilises-tu ? Une assez récente ?

    Mon PodFile est super simple:
     
    target 'StickersBeacon' do
    pod 'EstimoteSDK', '2.4.0'
    end

    Il aurait peut-être effectivement fallu commencer par là  pour nous mettre sur la voie ;)

    PS : La prochaine fois merci d'utiliser les balises CODE pour encapsuler du code ou un contenu de fichier, c'est plus lisible et ça formatte les choses correctement.

    Du coup j'ai regardé le PodSpec de ce pod EstimoteSDK, et il indique entre autres que le pod est compatible iOS7+ (donc pas de restriction à  iOS8), et dans les frameworks système dont il dépend, il n'y a pas du tout de mention du framework Metal. Du coup je ne sais pas d'où vient ta dépendance à  Metal, mais sans doute pas de là ...


    Si tu n'as vraiment que ce Pod dans ton Podfile, comme lui ne dépend pas de Metal, c'est que ça vient d'autre part. Quand tu fais un "pod update", CocoaPods te met-il des warnings, comme quoi par exemple certains Build Settings de ton projet overrident les Build Settings réglés par CocoaPods ? Ce qui pourrait expliquer ton problème, si dans les Build Settings de ton projet il a manuellement été rajouté une dépendance à  Metal, même si CocoaPods ne rajoute pas cette dépendance, si elle a été marquée en dur dans ton projet par un ancien collègue ou par une fausse manip et qu'elle est encore là , le problème viendrait de là ...
  • pistonman33pistonman33 Membre
    #6

    OK merci Aligator, donc je présume que si je mes platform IOS 7.0 il ne charge que les librairies compatible IOS 7 mais pas nécessairement IOS8 ?


    Que conseilles tu aussi de faire si j'ai toujours l'erreur du framework not found malgré avoir défini la platform ios 7 ?

  • pistonman33pistonman33 Membre
    #7

    Voici mon pod update



    
Update all pods
    
Analyzing dependencies
    

    
CocoaPods 0.36.0.rc.1 is available.
    
To update use: `gem install cocoapods --pre`
    
[!] This is a test version we'd love you to try.
    

    
For more information see http://blog.cocoapods.org
    
and the CHANGELOG for this version http://git.io/BaH8pQ.
    

    
Downloading dependencies
    
Using EstimoteSDK (2.4.0)
    
Generating Pods project
    
Integrating client project

    Désolé j'avais oublié les balises code.

  • pistonman33pistonman33 Membre
    #8

    J'ai aussi fait une recherche de Metal dans le build settings de Pods et de Mon Projets mais je n'ai rien trouvé :-(


    Je voulais aussi savoir si c'est bien le Build Settings de Pods qui prime ?


  • pistonman33pistonman33 Membre
    #9

    Pour info je suis sur Xcode 6, je ne sais pas si ca influence quelque chose car j'ai trouvé pas mal de gens qui proposait de repasser sur Xcode 5 ....


  • AliGatorAliGator Membre, Modérateur
    #10

    J'ai aussi fait une recherche de Metal dans le build settings de Pods et de Mon Projets mais je n'ai rien trouvé :-(
    Je voulais aussi savoir si c'est bien le Build Settings de Pods qui prime ?

    Les Build Settings injectés par CocoaPods le sont via des fichiers ".xcconfig".

    Ces settings définissent les valeurs par défaut, mais rien ne t'empêche de les surcharger dans l'interface de Xcode en allant dans l'onglet Build Settings du projet ou du target.

    Pour chaque Build Settings, s'il y a une valeur indiquée pour ce setting au niveau du target, c'est celui-là  qui prime. Sinon c'est celui au niveau du projet s'il existe, sinon c'est celui au niveau du xcconfig, et seulement si aucun des 3 niveaux ne définit de valeur c'est la valeur par défaut.
    Et pour chaque niveau de Build Settings, soit tu override complètement, soit tu utilises "$(inherited)" pour hériter des Build Settings du niveau parent et y rajouter d'autres options.

    Du coup si tu overrides certains build settings, entre autres ceux mis par CocoaPods :
    - Si tu les écrases, donc que tu n'utilises pas $(inherited) et que tu remplaces au lieu de rajouter, tu risques de perdre certains settings mis par CocoaPods qui sont pourtant là  pour permettre à  ton code de compiler correctement
    - Et si tu ne fais que rajouter des réglages par exemple $(inherited) tu conserves les réglages CocoaPods donc c'est bien. Mais ça ne t'empêche pas de rajouter des choses inutiles (comme une dépendance à  Metal) à  la main qui va empêcher ton code de compiler (mais ça n'aura rien à  voir avec les settings qu'aura mis CocoaPods)
  • pistonman33pistonman33 Membre
    #11

    OK merci aliGator pour ces éclaircissements.


    Si j'ai bien tout compris, on peut aussi mettre des directives dans le PodFile comme ceci par exemple



    
post_install do |installer_representation|
    
installer_representation.project.targets.each do |target|
    
target.build_configurations.each do |config|
    
config.build_settings['CLANG_MODULES_AUTOLINK'] = 'NO'
    
config.build_settings['ARCHS'] = 'armv7 armv7s'
    
end
    
end
    
end

    Et donc celles-ci seront mises dans le xconfig par cocoapods après un pod update?


    Si c'est bien cela, ce n'est pas la meilleure méthode car tout est centralisé dans le fichier Podfile et c'est cocoapods qui est toujours celui qui prime ? Sinon je trouve ça brouillon si il y a des directives dans les build settings et fichier pods?


    De plus est il possible de tout faire dans un fichier Podfile ?


    Merci en tout cas pour ton aide.


  • AliGatorAliGator Membre, Modérateur
    #12

    OK merci aliGator pour ces éclaircissements.
    Si j'ai bien tout compris, on peut aussi mettre des directives dans le PodFile comme ceci par exemple


    
post_install do |installer_representation|
    
installer_representation.project.targets.each do |target|
    
target.build_configurations.each do |config|
    
config.build_settings['CLANG_MODULES_AUTOLINK'] = 'NO'
    
config.build_settings['ARCHS'] = 'armv7 armv7s'
    
end
    
end
    
end
    Et donc celles-ci seront mises dans le xconfig par cocoapods après un pod update?
    Si c'est bien cela, ce n'est pas la meilleure méthode car tout est centralisé dans le fichier Podfile et c'est cocoapods qui est toujours celui qui prime ? Sinon je trouve ça brouillon si il y a des directives dans les build settings et fichier pods?
    De plus est il possible de tout faire dans un fichier Podfile ?
    Merci en tout cas pour ton aide.

    Alors oui on peut mettre des directives dans le Podfile avec ce "post_install" (qui est donc un petit script ruby à  exécuter en "post install" donc après l'installation des pods).

    Mais ce script de post_install a plutôt pour but de modifier les settings des Pods pour contourner certaines conditions, comme par exemple dans le script que tu cites, forcer les architectures des pods à  armv7 et armv7s (en particulier le but est ici je suppose de ne pas inclure arm64 comme c'est le cas par défaut, peut-être parce qu'une des librairies que tu utilises ne supporte pas encore l'architecture arm64 " faudrait qu'ils se bougent le c*l d'ailleurs car c'est maintenant obligatoire et tu ne peux plus publier d'application sur l'AppStore sans l'architecture arm64...)

    Donc ces scripts de post_install sont pour modifier les build settings des Pods, parce qu'à  chaque fois que tu fais un "pod install" ou un "pod update" c'est CocoaPods qui regénère le projet "Pods" et donc écrase les Build Settings du projet Pods et des targets des pods. Mais c'est décorrellé des Build Settings de ton propre projet, celui qui contient ton application.

    C'est justement aussi l'intérêt du fonctionnement de CocoaPods, tout ce qui est lié aux pods / librairies externes, avec leurs propres settings (qui sont souvent propre à  chaque lib, chaque lib ayant parfois besoin de Build Settings spécifiques), est géré dans un projet Pods.xcodeproj dédié qui est bien séparé de ton xcodeproj à  toi qui contient le code de ton Application avec ses propres Build Settings. Chacun chez soi.
  • pistonman33pistonman33 Membre
    #13

    Merci aligator pour toutes ces explications ! 


    En tout cas je sais à  qui m'adresser pour des soucis avec cocoapods!


    En tout cas c'est un super outil !


Connectez-vous ou Inscrivez-vous pour répondre.