search

mrRay / vvopensource

OSC and MIDI frameworks for OS X and iOS, a framework for managing and rendering to GL textures in OS X, and a functional ISF (interactive shader format) implementation for OS X.
231 stars 33 forks source link

Reconfigure build process for iPhone static libraries #3

Closed ndonald2 closed 10 years ago

ndonald2 commented 10 years ago

From the documentation:

To the best of my knowledge, Apple doesn't allow you to use external libraries in iPhone apps, so the workaround is to compile VVOSC as a static library, install it on your dev machine as an SDK, and compile against it.

Compared to the way the majority of iOS external static libraries are built and installed (in my experience), this is a relatively cumbersome process with a number of disadvantages. Any chance it could be reconfigured?

Typically, a separate project file is used to build a static library target which can be added as a dependency in another project simply by dragging said project file into the workspace, adding the dependency, linking to the library, and adding a few header search paths.

See, for example, The Amazing Audio Engine

The author of TAAE also has a great template for creating universal (simulator and device) static libraries for iOS here. This allows a single linkage to work for both simulator and device targets, which as far as I know can't be done with an SDK (build settings doesn't let you specify separate SDK paths for device vs simulator).

Just some feedback from someone who really appreciates your library - simplifying the install process would be very helpful.

Thanks!

ndonald2 commented 10 years ago

This allows a single linkage to work for both simulator and device targets, which as far as I know can't be done with an SDK (build settings doesn't let you specify separate SDK paths for device vs simulator).

Scratch that, I forgot the ($PLATFORM_NAME) variable can be used to do this.

Either way, a non-SDK static library option might be worth considering. Cheers!

mrRay commented 10 years ago

i restructured this a while ago and simply forgot to close the issue; frankly, i think dealing with explicit static libs is more of a pain in the ass than an SDK (which is basically just a static lib + header files in a predefined location), but if people feel more comfortable with a plain ol' static lib because they're more prevalent then i'm not going to argue!

ndonald2 commented 10 years ago

@mrRay Excellent, thank you! The static lib dependency approach has the added bonus of making it much easier to add the dependency to a project using a git submodule. Fresh clones of a project no longer require building the SDK from its own project and configuring the linkage.

Cheers