ocio-dev@lists.aswf.io | External Dependencies

Home Messages Hashtags Subgroups Calendar

Date Date 1 - 7 of 7

External Dependencies

Jeremy Selan <jeremy...@...> #520 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
More
Malcolm Humphreys <malcolmh...@...> #523 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 toggle quoted message Show quoted text 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
More
Jeremy Selan <jeremy...@...> #521 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
More
dbr/Ben <dbr....@...> #528 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 toggle quoted message Show quoted text 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
More
Deke Kincaid <dekek...@...> #526 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 toggle quoted message Show quoted text 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
More
Malcolm Humphreys <malcolmh...@...> #530 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: toggle quoted message Show quoted text 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 >>
More
Jeremy Selan <jeremy...@...> #527 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 >>
More

1 - 7 of 7

1

Previous Topic Next Topic

Home Hashtags Subgroups Calendar Terms