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

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.

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.