Never use the dependencies from RPM repositories, because you have to face
so many issues, such as Linux file system, static or dynamic linking, GCC +
libstdc++, portable deployment etc.

The logic in our MultiverseStudio<http://multi-verse.io/> is easy, also I
applied this methodology to the compilation of OIIO into it.

   - Application Level (MultiverseStudio, Maya)
   - 1st Level Dependencies: USD Alembic
   - 2st Level Dependencies: OIIO
   - 3rd Level Dependencies: boost zlib jpeg tiff OpenEXR libgit2
   OpenSubdiv ptex etc...
   - 4rd Level Dependencies: (Platform-specific, Windows SDK, MacOSX SDK)

Sometimes the 3rd level would be also used by the above levels, but that's
fine. And the 1st and 2st levels sometimes also ship the Python binding. So
1st + 2nd, the final library would be dynamic. The tricky part is the 3rd
level, usually I always prepare them in static way, because

   1. App + 1st + 2nd might need some specific version of 3rd.
   2. 3rd would be used almost everywhere within the applications, such as
   boost, OpenEXR.
   3. Only exception is sometimes the restriction of license, such as LGPL,
   so build the library in dynamic way.

So your final distribution would be just the dynamic libraries at 2nd and
1st levels with Python binding, and they're portable, no need for any
external libraries from system, and easy to update any of them if really
necessary. Even if you're going to upgrade Linux, you don't have to rebuild
all the libraries but you could use them directly on new system.

On Sat, Sep 23, 2017 at 2:53 AM, Richard Shaw <[email protected]> wrote:

> On Fri, Sep 22, 2017 at 12:50 PM, Ran Sariel <[email protected]>
> wrote:
>
>> Thanks Richard for setting the copr
>>
>> Not sure what the rpm is using in terms of different dependency versions.
>> We need our own versions of, exr/ boost / ocio etc.
>> So I'd rather solve the linking issue instead of just installing a built
>> package
>>
>
> Except what was build in COPR it's using what's available in CentOS / EPEL.
>
> Thanks,
> Richard
>
> _______________________________________________
> 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

Reply via email to