NO, it's important that no part of R3DSDK is distributed with OIIO. We can make
calls to it, but we need to rely on it being already on the system at build
time.
I'm sorry, with DigiPro and SIGGRAPH prep, I may not have time to watch this
thread closely (let alone reply coherently) for the next week.
-- lg
> On Jul 26, 2019, at 1:06 PM, Alex Hughes <[email protected]> wrote:
>
> That `target_compile_definitions`
> Is a clever way of doing the runtime linking that R3D requires.
>
> Question for LG though...
> Do we want to provide the R3DSDK redistibutables with OIIO, in which case I
> would set the R3DSDK initializer to look relative to itself.
> Another option could be environment variable based so at runtime when the
> R3DSDK needs the path to the libraries, it could pull from the environment.
> The way will was doing it in his demo was using the preprocessor directives
> to define the redist path. Which I think may cause problems because I doubt
> people are compiling against the live libraries in their environment.
> Also, the "add_oiio_plugin" macro doesn't seem to set the passed
> "DEFINITIONS" in a way that would allow the compilation of the plugin to have
> the preprocessor directives applied.
> I played around with modifying the "libOpenImageIO" CMakeLists file and
> added a "target_compile_definitions" call with my required definitions but
> having plugin specific logic in the core lib CMakeLists file doesn't seem
> like the right way to approach this.
>
> So I guess, to simplify the above, the R3DSDK requires runtime linking of the
> sdk and requires a path in there. I am inclined to try to read an environment
> variable and fallback to looking in the same directory for the libraries.
> Does that seem like a good way to do it?
>
> I've got a working R3DInput plugin working I think and am just getting the
> test cases up. But I hopefully will have a PR open soon.
>
> -Alex
>
>
>
> On Fri, Jul 26, 2019 at 5:15 PM Alex Hughes <[email protected]
> <mailto:[email protected]>> wrote:
> Thanks Will,
>
> I would love to include that in my PR if that's ok with you, with credit of
> course.
>
> -Alex
>
> On Fri, Jul 26, 2019 at 8:18 AM Will Rosecrans <[email protected]
> <mailto:[email protected]>> wrote:
> I recently started making a CMake find module for the R3D SDK. It's uhhh...
> not quite production ready, (I think it won't work on a Mac yet, and I
> haven't tested it on Windows) but it might be a handy starting point. Feel
> free to use it or crib from it, etc. It has a trivial example that makes an
> OIIO image buf.
>
> https://github.com/wrosecrans/ImageTypes
> <https://github.com/wrosecrans/ImageTypes>
>
>
>
> On Thu, Jul 25, 2019 at 1:38 PM Alex Hughes <[email protected]
> <mailto:[email protected]>> wrote:
> I could take a look at it since I brought it up.
>
> I've never taken a stab at an OIIO plugin but there are lots of examples and
> the docs seem reasonable.
> I would be tackling it on my own time without company support at this point
> because we don't have an immediate need for it here.
>
> Is the FFMpeg plugin a decent example to base work off of? At least for the
> ImageInput?
>
> -Alex
> _______________________________________________
> Oiio-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
> _______________________________________________
> Oiio-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
