CorePlot et Swift sur iOS

yoannyoann Membre

Salut tout le monde,


 


Je suis en train de faire une application pour tester la précision des capteurs de l'iPhone 6 (gyro, accéléromètre, baro, etc.).


 


Vu que c'est une application jetable qui va uniquement me servir à  ressortir des données pour juger de la fiabilité des capteurs en ULM, je me suis dit que j'allais le faire en Swift.


 


Je suis en train d'essayer d'inclure CorePlot et je me prend cette erreur :



/Users/yoanngini/Desktop/SensorTest/SensorTest/Bridging-Header.h:12:9: 'CorePlot-CocoaTouch.h' file not found

J'ai inclus CorePlot dans mon projet en faisant un simple clone et en ajoutant le projet Xcode de CorePlot en sous projet de mon SensorTest.

 

J'ai ajouté la lib CorePlot dans mes links et en dépendance, ça compile tout comme il faut au cmd B cependant les headers ne sont pas là .

 

Ils sont tagué comme projet dans CorePlot. Il devrait donc se trouver dans mon dossier de build (~/Library/Developer/Xcode/DerivedData/SensorTest-.../Build/Products/Debug-iphonesimulator) avec le .a mais ils ne sont pas là .

 

Quelqu'un sait d'où viens mon problème ?

 

Hormis le bridging header, il y a quelque chose de spécifique à  faire pour que les headers des sous-projets ObjC soient accessible en swift ?

 

 


 


Réponses

  • AliGatorAliGator Membre, Modérateur
    juin 2015 modifié #2
    C'est quoi cette idée bizarre d'inclure encore les projets à  la main ?! Pourquoi se prendre la tête avec ce genre de settings plutôt que d'utiliser Carthage ou CocoaPods ?


    Et sino t'as spécifié quel était le BH?
  • yoannyoann Membre

    Je trouve incroyablement lourd et casse couille de passer par des truc comme CocoaPods ou Carthage. Tout simplement.


     


    Je ne vois pas pourquoi je vais passer par un système qui me rajoute de la complexité au projet pour faire un truc aussi simple que :


    " un submodule


    " une inclusion de fichier


     


    C'est d'ailleurs beaucoup plus rapide pour la diffusion de projet et le travail en équipe. Xcode est le seul outil nécessaire, pas besoin de se faire chier à  installer chez tout le monde des outils supplémentaire et à  gérer des bug lié à  ces outils là .


     


    Le cout travail manuel autour de la gestion des lib est bien plus faible que le cout que représente l'utilisation d'un outil tiers.


     


     


    Sinon pour la partie BH, dans les réglages de la target j'ai bien mis :



    SWIFT_OBJC_BRIDGING_HEADER = SensorTest/Bridging-Header.h

    Le chemin est juste, il est bien traité par Xcode qui me fait une erreur :



    SensorTest/Bridging-Header.h:12:9: 'CorePlot-CocoaTouch.h' file not found

    Et effectivement le fichier n'est pas dans le dossier de build comme il devrait l'être.


  • AliGatorAliGator Membre, Modérateur
    Je n'ai qu'un mot à  dire : LOL.


    On voit que tu codes pas souvent avec des dépendances et de la maintenabilité et que tu n'as clairement pas compris les avantages des outils de DM (que ce soit CP, Carthage, npm, RubyGems, Gradle, Maven ou n'importe quel autre)
  • yoannyoann Membre

    Ali, tu es gentil mais j'en ai rien à  battre de ton point de vue sur la manière dont je gère mes sources.


     


    Soit tu participe intelligemment au sujet en répondant à  la problématique soit tu laisse tomber.


     


    Tes avis d'église ne m'intéresse pas.


  • Et si on gardait un ton courtois  :p


  • AliGatorAliGator Membre, Modérateur
    juin 2015 modifié #7
    Ce n'est pas vraiment un avis d'église (surtout que je suis loin d'être fan de Carthage par exemple, donc c'est loin d'être par exemple une solution que j'aurais recommandé si j'avais juste voulu faire de la pub pour mes préférences personnelles !)

    C'est une solution que je te donnais. A savoir utiliser un des multiples outils qui solutionneraient ton problème assez classique de la galère d'intégration de code tiers avec Xcode.

    Mais bon si tu ne veux pas de mes solutions, libre à  toi de continuer à  galérer.
  • yoannyoann Membre


    Ce n'est pas vraiment un avis d'église, mais une solution que je te donnais.

    Mais bon si tu n'en veux pas, libre à  toi de continuer à  galérer.




     


    Revois ta formulation alors car ton poste n'est pas une solution mais un foutage de gueule.


     


    De plus, c'est exactement comme si je posais une question ObjC et que tu me répondais "non mais fait ça en swift ça sera plus hype".

  • CéroceCéroce Membre, Modérateur
    @yoann: ça pourrait être intéressant de voir comment Cocoapods s'y prend, même si tu ne désires pas l'utiliser au final. Si ça fonctionne tu pourrais reporter leur solution dans ton projet.
Connectez-vous ou Inscrivez-vous pour répondre.