Coming back to this... I totally get why it would be useful to be able to do a build of just the Python bindings, on top of an already-built libOpenImageIO (though also a little dangerous, you're kind of taking it for granted that they are in sync). And for packaging systems, why it's helpful to essentially split the core library from the Python. We ran into a similar issue with Rez, where it was a PITA that it was pulling Python into the dependency constraint list for downstream apps that only wanted OIIO's core library.
I could see maybe a build option (off by default, of course) that would, when enabled, essentially let you point it to libOpenImageIO and have it just go with the fact that it's already built. I just don't have time at the moment to do this myself, but if somebody else could do it in a way that wasn't terribly intrusive to the build system (I'm worried about primarily about preserving its maintainability), I would gladly accept a PR that adds this capability. > On Oct 21, 2020, at 9:19 AM, Deke Kincaid <[email protected]> wrote: > > This is about both efficiency and our dependency chain. Essentially because > of the upcoming python 3 move and more and more packages depending on OIIO > (Material X, USD, etc...). OCIO 1.x does not support python 3 but OCIO 2.x > does. If you try to compile both OIIO's python 2 & 3 bindings it will fail > because of OCIO 1.x's lack of python 3. I need to compile cy2019/cy2020 > libraries for both python 2 and 3 so we can write proper tests to make sure > our updated code works on both python versions. It will be much easier to > separate OIIO python bindings from the core library so I'm I can lessen the > dependency chain and how many times I have to recompile the core OIIO > library. Also in our dependency chain, any C libraries don't have to > needlessly depend on python anymore in this situation. I could technically > just build both and not copy one or the other into a oiio_python or oiio_core > package, so a lot of this is really about speed and efficiency (especially > around tests). > > Excuse my meandering explanation but hopefully, that makes sense. Alembic > and MaterialX allow this. Unfortunately, USD does not. > > On Wed, Oct 21, 2020 at 12:04 AM Larry Gritz <[email protected] > <mailto:[email protected]>> wrote: > On Oct 20, 2020, at 7:28 PM, Deke Kincaid <[email protected] > <mailto:[email protected]>> wrote: >> >> Is there a way to compile the OIIO python bindings separate from the core >> libraries? I don't see an obvious way to turn the core libs off and point >> to a pre-existing external path for them. > > It never occurred to me that this would be useful. I always imagined that > they would be built together. > > I assume... that you're trying to add python bindings to an existing install > of the libraries only that you can't alter or rebuild? > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > > > _______________________________________________ > 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
