Re: External Dependencies
Jeremy Selan <jeremy...@...>
Yah, I'm in the same place. The OSX target is fine, it's the
ipod/ipad arm targets that fail. (The first error I encounter is that
when building yaml-cpp the compiler is tested by building a trivial
standalone binary, which is not available allowed on that arch).
-- Jeremy
On Wed, May 18, 2011 at 6:34 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
ipod/ipad arm targets that fail. (The first error I encounter is that
when building yaml-cpp the compiler is tested by building a trivial
standalone binary, which is not available allowed on that arch).
-- Jeremy
On Wed, May 18, 2011 at 6:34 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
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 <dbr....@...> 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 <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. >>exception of two libraries cmake pulls at build time from ext: >> tinyxml,For the core OCIO library this would be rather simple, with the >>
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 >>