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 <jere...@...> 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 > <malcol...@...> 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 <jere...@...> 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 >>