[Bf-usd] Static Linking and Plugin Paths

[Sybren A. Stüvel]

Hello all,

In the USD Interest group I got two responses, one of which from Mark
Tucker who helped me solve this isssue:

> I'm not sure if this helps, but Houdini also has a need to explicitly
> scan the HOUDINI_PATH for USD plugins. We do this by scanning the
> HOUDINI_PATH after initializing USD, and calling
> `PlugRegistry::GetInstance().RegisterPlugins(pluginpaths);`, where
> `pluginpaths` is a vector of all the USD plugin paths we find within
> the HOUDINI_PATH. This results in a different initialization order
> than if we used environment variables or modified the USD library to
> change its plugin loading, but it works for us, and did not require
> any changes to the USD library.
>
> Mark
This approach seems to work for Blender as well, so I'll be phasing out
the our patch of the USD library.

Kind regards,

Sybren

On 31-08-2020 15:35, Sybren A. Stüvel wrote:
>
> Hello all,
>
> I have just sent the below mail to the USD Interest google group.
> Since that group is not public, I send that email here as well. That
> way everybody knows what's being discussed.
>
> Blender is statically linking most libraries, including USD. It's also
> built in such a way that it can be moved to (or an archive unpacked
> into) an arbitrary directory. This means that at build time, there is
> no way to know what the path of the USD Plugin files will be. Because
> of the static linking in combination with USD's static initialisers,
> it's also not possible for Blender to set any environment variables,
> or to run any code before the static initialisers run.
>
> The USD library has some code to find files relative to the
> executable, but it doesn't search in our Blender-specific location.
> This would require knowing the version of Blender that's running, so
> it would put Blender-specific code into the USD library, which is of
> course not desirable.
>
> To get Blender and USD playing nicely together, I had to hack the USD
> library to defer the loading of plugins (see
> https://developer.blender.org/diffusion/B/browse/master/build_files/build_environment/patches/usd.diff).
> With this hack, the static initialiser is still there, but is a no-op,
> and the plugin loading is moved to a function that can be called from
> Blender itself. That function gets the plugin path from Blender.
>
> This is of course an ugly workaround, and not every Blender developer
> is happy with it
> (https://lists.blender.org/pipermail/bf-committers/2020-August/050645.html).
> Is there anything that can be changed in the USD library to support
> Blender's use case? I could clean up my patch and make its behaviour
> optional via some build-time option that's off by default. That way
> the default behaviour of the USD library doesn't change, but the
> ability for a program to determine the plugin path at runtime remains.
>
> Kind regards,
> Sybren
>
> -- 
> dr. Sybren A. Stüvel
>
> Blender Software Developer
>
> https://blender.org/
> https://cloud.blender.org/
>
-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20200831/6e836672/attachment.htm>