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.