I’m not familiar enough with USD to determine what deps are must haves and what are nice to haves, pretty sure brian may have some insights there.
Just to be sure, going foward, USD + select (TBD) deps dynamic for all platforms? ( I can manage windows+linux, but if linux works pretty sure you’ll be able to manage mac) if so i’ll work with brian to get atleast the library part taken care of.
Yes, I think we should make at least USD, OpenVDB, OpenColorIO and TBB dynamic for all platforms. There may be some things for binary add-on authors to deal with, but it’s the same for other 3D apps. We probably need to make some tweaks and document the solutions for avoiding conflicts.
Sergey also agreed going to dynamic libs is what we need to do.
TBB is a must & so is Boost – Regarding OpenVDB / OCIO - OpenVDB is all silo’d off into it’s own plugin/library and OCIO is pretty specific to roughly ~4 lines of code in just hdx if I’m not mistaken, it’s some very basic support for supporting color management configs.
I personally just ended up going fully static here - but there is “more work” involved at managing dependencies (py dependencies on each other are cyclic and would need to be stopped from Tf manually loading them in – along with most of Tf’s library loading ability can/should be disabled if those resources are managed within a static build context – and since Pixar didn’t spec any of this out for a static build - Tf pretty much always assumes it’s comfortably within a dynamic context.)
Also - yes my binary size blew up. Currently it’s sitting at half a gig now - which I think is up at least twice to what it used to be.
That’d be the approximate damage done.
Also, effectively 90% of TBB is wrapped to one central place in all of USD - you’re going to want to look at WorkDispatcher::WorkDispatcher(), it is here that Pixar has centralized their dependency on TBB - as it is in charge of threading all the templated Run() & Cancel() calls throughout USD, accompanied by a Wait() until those tasks complete. So that’s a plus.
For those familiar with TBB, it’s simply a tbb::task_group for each task context, which deduces a callable “task” to execute → ()().