toggle quoted messageShow quoted text
Yep that's what I saw last night, everything builds for a OSX target fine other than PyOpenColor which fails to link because of some Python symbols. Did you find a fix for this?
The xcode build spits stuff all over the place which I would like to clean up a bit.
Ill try to get the iPhone (and maybe even the android) targets setup after this.
Sent from my phone.
dbr/Ben <db...@...> wrote:
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
> -- 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.
>> On 18 May, 2011,at 02:15 AM, Jeremy Selan <jere...@...> wrote:
>> 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