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:
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. >>
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 >>


Malcolm Humphreys <malcolmh...@...>
 

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 > 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 >>


Deke Kincaid <dekek...@...>
 

funny I just saw the article about Lasseter watching dailies for all
of Cars 2 on his ipad2. There is already the horror of people looking
at quicktimes on different machines and it doesn't always look the
same on windows and macos. So this sounds like a great idea.

-deke

On Tue, May 17, 2011 at 16:43, 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.

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


dbr/Ben <dbr....@...>
 

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


Jeremy Selan <jeremy...@...>
 

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


Malcolm Humphreys <malcolmh...@...>
 

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


Jeremy Selan <jeremy...@...>
 

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