Heh, an OCIO image viewer for iPad? \o/

I've compiled OCIO via the Xcode project generator a while ago, when adding the CSP prelut support (to get Xcode's nice error reporting) - wasn't for iOS, but the only problem I vaguely recall was something minor related to a Python header path or something

On 18/05/2011, at 2:12, Jeremy Selan <jeremy...@...> wrote:

We can certainly wait.  I'll do all my development on a local
(jeremys) topic branch, which should more than suffice until around
siggraph.

-- Jeremy

On Tue, May 17, 2011 at 9:26 AM, Malcolm Humphreys
<malcolmh...@...> wrote:

Can I give it a go before you decide? I was looking at andriod porting a
while back as well which I guess is along the same lines.

.malcolm

On 18 May, 2011,at 02:15 AM, Jeremy Selan <jeremy...@...> wrote:

Folks,

I've been trying to get OCIO compiled for the iPad (think siggraph
tech demo), and I've been having a very hard time getting the XCode
cmake exporter to generate a working project. I've followed all the
online instructions, upgraded to the latest cmake, and even
investigated not using xcode and just cross-compiling to create a
static arm library - but no success thus far. Has anyone else given
this a shot? I've pinged a few people in the cmake / ios community,
and their universal recommendation is, if possible, to not rely on
cmake to generate the xcode project but it instead just add the
library to your native project as source files.

For the core OCIO library this would be rather simple, with the
exception of two libraries cmake pulls at build time from ext:
tinyxml, yaml-cpp.

What would people's thoughts be on pulling these libs back into
src/core (as they used to be)? All the other libraries
(lcms,sphinx,...) would remain in ext. This would allow people to
easily build the core library, even in circumstances where cmake is
not available / appropriate. (Basically all you'd have to do is
provide the constants in the OpenColorABI.h and the rest would be
simple.) I really like the cleanliness of the current cmake build
system, but I imagine in the context of high performance mobile
devices this will come up more and more, and my gut feel is that any
native cmake -> xcode (or equivalent) process will be fragile in the
long term.

-- Jeremy