Alex, I think we should handle it much like the other formats for which we use
external libraries -- assume it's installed on the system somewhere (don't
embed it), provide CMake variables (e.g. R3D_ROOT_DIR) to hint or override the
location where it should be found, and if not found the warning might be nice
if it said the URL for the red.com <http://red.com/> web page where users can
find the SDK to install it themselves.
Another task that will need to be done is to find a minimal r3d file that we
can use as a test case, preferably as small as possible, and also not
containing any proprietary info or licensing requirements that would make it
bad to check into testsuite.
I encourage you guys to keep this discussion going right here on the mail list.
And don't be afraid to break it into many incremental PR's. For example, maybe
the first one is just the FindR3DSDK.cmake and changes to
externalpackages.cmake to look for it and either print where it was found or
that it wasn't. Then the next PR might be just the skeleton of
r3d.imageio/r3dinput.cpp that is capable of merely opening the file so that
"iinfo foo.r3d" would correctly report it as a r3d file and know the
resolution. Then the next might be able to have "iinfo -v" report all the
relevant metadata. Then the next might be able to correctly read the frame for
whatever the most common configuration is. And so on. Breaking into small
pieces will make them easy to review, and also easier for multiple people to
share the work and collaborate (as opposed to the whole thing being done
outside our visibility and then presented as a single completed PR that does
everything). And if I can see the progress along the way in this manner, I can
also help steer you to the right idioms before you're too far down any wrong
roads.
-- 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
