Cocoapod support??

Home Forums OpenEars Cocoapod support??

Viewing 4 posts - 1 through 4 (of 4 total)

  • Author
    Posts
  • #1017382
    fushunpoon
    Participant

    Hi Halle,

    OpenEars could be much more easily be used as a part of a large project if only it were supported on Cocoapods.

    I’ve tried to make a Cocoa podspec for it, including all OpenEar sources and its dependencies’ sources into the project. However, I ran into into 37 linker errors that look like this:

    Undefined symbols for architecture i386:
    “_delete_features”, referenced from:
    -[GraphemeGenerator init] in libPods-VoiceArmApp.a(GraphemeGenerator.o)
    “_delete_utterance”, referenced from:
    -[GraphemeGenerator convertGraphemes:] in libPods-VoiceArmApp.a(GraphemeGenerator.o)
    “_delete_wave”, referenced from:
    -[FliteController say:withVoice:] in libPods-VoiceArmApp.a(FliteController.o)
    “_feat_copy_into”, referenced from:
    -[GraphemeGenerator init] in libPods-VoiceArmApp.a(GraphemeGenerator.o)

    I’m not sure how to resolve it. Any ideas?

    Hok

    #1017394
    Halle Winkler
    Politepix

    Welcome Hok,

    I am going to look into what is involved in creating a Cocoapod spec once the next round of releases are out since Orta let me know there was interest and I also think it’s a good idea if there is compatibility between the Cocoapod system and how OpenEars is developed and released. Unfortunately I can’t troubleshoot it with you in advance of getting time to look things over myself and figure out what will be involved in that task, but I wanted to let you know that I also think it would be a useful development and it is on my own task list.

    #1017400
    fushunpoon
    Participant

    Hi Halle,

    I’m glad that it’s on the roadmap somewhere. It would make development with OpenEars much more manageable for everybody.

    Cocoapods works by sticking all Objective-C sources of a Framework into its own fake Framework directory, and then generates you a workspace that would tie your project’s various targets up with the frameworks they depend on. The main challenge is to have OpenEars’ dependencies compiled and linking correctly with the rest of the sources. It doesn’t seem like a trivial task.

    #1017401
    Halle Winkler
    Politepix

    Well, development with OpenEars is 1. dragging a folder into your project and 2. starting to code, so I’m not sure the win is that big in terms of manageability, but Cocoapods is a very cool project and I’m happy to look into participating. There are no library dependencies in the sense you’re describing since they are all shipped as part of OpenEars’ distribution (using other versions of its library dependencies are probably why you have errors above), but a Cocoapods spec has to work with OpenEars’ license which is not OSI.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.