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]> 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]> > 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 >> >> >> >> On Thu, Jul 25, 2019 at 1:38 PM Alex Hughes <[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] >>> 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 >> >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
