I definitely can't speak for Larry. That said... I think that trying to
set the path for the runtime libs from the compile_definitions approach
isn't great outside of the little sample. It can only work when the binary
is run on the system where it was built. If making something real that
will be shipped to another box, the ${RED_RUNTIME_LIBRARIES} will have to
be stuffed into CMake's installs stuff, so that it can get packaged. I
think the runtime libs need to match the static library that you link to at
build time, and I wouldn't expect good results if the end-user had an
older/newer R3DSDK installed on their machine to try and load from at run
time.
As far as I can tell, it actually is fine to redistribute the runtime
libraries. You just can't redistribute stuff outside that
"Redistributable/" directory (like the .a static lib, the headers, the
documentation, etc.). (I'm Not a lawyer, never played one on TV, don't
take legal advice from a rando on the Internet, etc.) For example, I don't
need to download the SDK to run a copy of Resolve or Nuke that was built
with R3D support. I can just install Resolve or Nuke, and they supply the
Redistributable libs along with their application. It seems analogous to
how you can't generally ship MS compilers and libs with your app on
Windows, but you can ship the MSVCRT DLL that is needed at runtime.
The SDK license calls out having a permission to distribute the
redistributable:
> "... distribute Redistributable Software in original form only, that is
installed only in a private (non-shared) directory location that is used
only by Your Developer Programs..."
So I think even if libOpenImageIO.so were installed in a shared location
like /usr/lib, the red libs would have to be in something like
/usr/lib/OpenImageIO/redstuff.so, so that other apps that use R3D but not
the system OIIO install wouldn't accidentally pick up runtime libs from a
different SDK version. The fact that they care where you install it is
clearly only something that would come up if they do expect you to install
it in the first place. You can't include any R3D SDK headers in the
redistributable, so the public header for an OIIO R3D plugin couldn't
include it or use any types from it, but the implementation .cpp file can
depend on it, and no apps using OIIO would ever need to see or have the
private headers. You wouldn't use R3DSDK::Clip in a public header, but
rather some PIMPL style OIIO::AlexClip which has a mysterious void* field
that the implementation can cast as a pointer to a Clip. Something like
that. It's a bit more grody than using an open source library, but I think
it's possible to do it without too much trouble while staying in the
boundaries.
Or just make the R3D plugin a hard opt-in, and only let users use it if
they have the SDK installed and not worry that it isn't very flexible.
Might be easiest to start like that, and sort out the technical details,
then come back later to sort out how best to deal with deployment stuff to
make it more convenient. But I don't think it's necessary. Maybe after
SIGGRAPH season, Larry can get an opinion from one of his contacts at R3D.
Obviously, their opinion would carry a heck of a lot more weight than mine
if they think I am misunderstanding any of this. :)
And yeah, if the CMake I started is useful for you, go nuts and throw it in
whatever you want. It wasn't doing anybody any good just sitting on my
hard drive. That repo has a BSD license file, but if some other license is
more convenient for somebody, I can add it.
On Fri, 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]> 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
>
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
