search

jamoma / JamomaCore

Jamoma Frameworks for Audio and Control Structure
Other
36 stars 14 forks source link

iOS binary path needs adjustment #164

Open caseybasichis opened 11 years ago

caseybasichis commented 11 years ago

Building iOS libraries for the device or the simulator will overwrite the other.

Can we use build paths like $(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)

I think some folks have scripts that lipo the resultant binaries into one FAT binary though that may not be necessary.

tap commented 11 years ago

Building FAT means the compile time will double, but then the hassle of figuring out conflicts will be dramatically reduced. Not sure what's better, but I'm happy with whatever y'all do...

--••• •••--

On Tue, Jul 30, 2013 at 10:11 PM, Casey Basichis notifications@github.comwrote:

Building iOS libraries for the device or the simulator will overwrite the other.

Can we use build paths like /usr/local/jamoma/lib/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)

I think some folks have scripts that lipo the resultant binaries into one FAT binary though that may not be necessary.

— Reply to this email directly or view it on GitHubhttps://github.com/jamoma/JamomaCore/issues/164 .

caseybasichis commented 11 years ago

Does it double the compile time because it is compiling both ARM and 386?

If the current paths weren't broken as they are, I would still have to compile once for each platform, manually changing it in xcode. Is that the doubling of compiling time you are referring to? I don't see how there is any way to avoid that.

My experience with lipo is that it runs very fast for doing things like

lipo -create libdevice.a libsimulator.a -output libcombined.a

I don't have a preference for FAT libraries, it could go either way. The path issue, as it is, is not workable though.