Prime31's new build tools and linker errors

We have purchased a couple of Prime31 packages (Etcetera and Storekit), and have now spent well over a full man-week of time trying to get our own custom plugin to work along with Prime31's. Their forum (which is to my understanding their only path for support) has been no help at all, as posts left there have been removed (if a programmer other than the one who purchased the package tries to post it) or closed with no answers if posted by the individual who purchased the package.

Prime31's new, "latest greatest", build tools have apparently taken a HUGE step backwards in that they do not work with XML plists from custom plugins. We have even tried writing our own converter to convert our plists to OpenStep (which even Apple is moving away from), to no avail. We are unable to resolve the linker errors that ensue, and we are also unable to get ANY support from Prime31 at all!!

We have now spent far more than the money than the Prime31 packages cost in labor hours trying to integrate their plugins with our own custom plugin. This is unacceptable. There needs to be support for XML-based plists. It is my understanding the Prime31's build process is based on Python. Python has built-in support for XML (via plistlib which is part of a stock Python distribution).

Does this make sense to ANYONE?

We are able to actually make things work, but not in an automated fashion. To do so, we must disable our own post build process, and let Prime31's stuff run. We must then manually edit the Xcode project after the fact. This work flow is untenable.

Can anyone who has written Prime31 compatible plugins please help us? Any help at all would be greatly appreciated. We have now spun our wheels long enough, and may have to look for other options than Prime31's as their support is pretty much non-existant.

Thanks in advance - a very unsatisfied and unhappy Prime31 customer.

= Ed =

 

Wow, I'm glad I'm not the only one having problems with this...
http://forum.unity3d.com/threads/177861-Prime-31-Admob-Linking-Errors-FFFFUUUUU

I haven't had much trouble with Prime[31] until recently. No idea what they're doing over there now! For $50 per plugin, it really should just work.

 

It will be interesting t see if someone from Prime31 bothers to reply here. They seem to take a posture of ignoring/deleting things that they don't want to see. I hope that this is just my imagination, but having posts deleted from their forum and then another one locked without response does not engender a lot of faith right now.

Please prove me wrong Prime31.

FWIW, one of our very talented engineers came up with a "work-around". It's ugly, and not something I would recommend anyone try. It involves starting your plugin's post process by delaying it from running until after Prime31's post-process completes. Ugly as sin since this has to be done via a timed delay, so it's probably not entirely reliable.

= Ed =

 

To add a bit to what Ed wrote...

We wrote a plugin to do some iOS stuff, as we didn't find any existing plugin to do it. This required us to modify the Xcode project file after Unity's done with it, to add a new framework and some other things. Xcode project files are stored in NextStep plist format, which is very similar (but not identical) to JSON. The tools we had for manipulating the project file would read the NS plist format but would write in XML format. This was not a big deal because Xcode reads XML-style project files without trouble.

Enter the Prime31 plugins. After getting our questions dismissed (deleted, closed, whatever) we finally found a reference that the Prime31 tools only work with Xcode project files in their "original" format. So we wrote a converter to put the project file back into NS plist format, and verified that Xcode accepted this converted project file. But the Prime31 tools would not accept the project file. They continued to complain about being unable to find the "configurationList" which apparently means they were unable to parse the project file.

This is especially maddening because their project processing is written in Python, the standard Python distribution includes plistlib, a library for reading and writing XML-style plists, and Xcode comes with plutil, which reads plists in NS (old) style, XML, JSON, and binary, and writes XML, JSON, and binary. So there's practically no excuse for not supporting XML. That their tools won't even support the project file when converted to the old format suggests they are in fact performing a cardinal sin: parsing the comments that appear in the project file, which Xcode ignores, in order to identify things. I don't know what they're doing, but it clearly doesn't work, and doesn't seem very interoperable.

Our "solution" involved deferring our project processing until the last possible moment, just before their tools run (I couldn't make ours run after!) and firing up a separate process that waits a few seconds, then runs our processing code. As Ed said, very inelegant. It's allowed us to move forward for now, but it's been a big waste of time. All of this would have been helped if a nice error message like "can't parse project file" were in the log, instead of something so obscure.

--Damien

 

I tried out these solutions, in the end I found an alternative that worked for me. Thank you for expediting my attempts by sharing what you have already found. I also needed to delay my post build step until after Prime31's, but my post build step was a Unity Editor script, not an external system script, so it had to run on the main thread. I know this because I made a new thread, let it sleep for a few seconds, and when my script ran on the worker thread Unity gave me a message stating it needed to run on the main thread. I abandoned this approach partly because of that, partly because it was overcomplicated, but mostly because I felt dirty.

In the end a simple solution worked. I added the following parameter to my PostProcessBuild attribute:

Code (csharp):

1. public static class Build
2. {
3.    [PostProcessBuild(999)]
4.    public static void OnPostProcessBuild(BuildTarget target, string path)
5.    {
6.       /// code here is executed after Prime31's post build step
7.    }
8. }

 

Mike from Prime31 rocked at everything Unity related for the longest time. Have they gotten too big to provide ideal support now?

I was also disappointed to find that some of their plugins, which when first released, came with source code. But the latest versions were compiled down into libraries, and access to source code disallowed. Even the Prime31 PostProcessBuild script is compiled down now, so you can't even see what exactly it's doing or ideally how to write your own post process script to interact with it properly.

 

This was precisely the answer I needed. I'm using XUPorter to add further modifications to the XCode project (it's a great system, easy to mod if you look into it) and adding that attribute to XCodePostProcess.cs was all it took. Now Prime31 runs it's post processing first, followed by my own mods, which means my XCode project no longer requires any manual modification at all!

Thank you!

 

This still makes sense six years later in 2019.