ARCH_CONSTRUCTOR is used by pxr/base/arch/initConfig.cpp:ARCH_CONSTRUCTOR(Arch_InitConfig, 2, void) pxr/base/tf/initConfig.cpp:ARCH_CONSTRUCTOR(Tf_InitConfig, 2, void) pxr/base/tf/initConfig.cpp:ARCH_CONSTRUCTOR(Tf_InitConfigPost, 202, void) pxr/base/plug/initConfig.cpp:ARCH_CONSTRUCTOR(Plug_InitConfig, 2, void) pxr/base/vt/value.cpp:ARCH_CONSTRUCTOR(Vt_CastRegistryInit, 255)
and by the macros TF_REGISTRY_DEFINE TF_REGISTRY_DEFINE_WITH_TYPE
TF_REGISTRY_DEFINE_WITH_TYPE is only used by TF_INSTANTIATE_TYPE which is not used by anything
TF_REGISTRY_DEFINE is only used by TF_REGISTRY_FUNCTION and TF_REGISTRY_FUNCTION_WITH_TAG
these are used by every type in nearly every library
so the question is, can all of those explicit constructor initializations be called by an initUsd.cpp, and can the types be loaded not at dload time through static initialization, but can TF_REGISTRY_FUNCTION* be coerced to be run at runtime, after the dloads are finished, and before Tf_InitConfigPost is called, from initUsd.cpp?
Can some mechanism be leveraged to discover all the type registrations, for that purpose? Regex the code and do it manually? Make initUsd.cpp just a big "this is for game programmers!" file maintained manually that we can warn mainstream usd devs off of?
Can we make a special "game static linking mode" that uses a set of modified macros so that the system can be built as is, BUT ALSO compiled in the new, "no static initialization mode"?
To some degree the "game mode" would bypass the plugin loading mechanism, so the pluginfo's would have to be maybe built into the library as interned strings.
The end result would be a simple-to-link variant of USD for engines. Not for tools or DCCs but specifically for embedding in places where dynamic loading doesn't make sense, and where user configuration, such as loose plugins are undesirable because you want to avoid hacking soft-points.
@meshula At this stage, I found an error when searching for a plugin when executing code in a file
pxr\usd\ar\resolver.cpp
on the lineconst PlugPluginPtr plugin = _GetPluginForType(resolverType)
I get an invalid object. But I'll start from the beginning, maybe the thing is that I'm not building static libraries correctly or connecting them to the project incorrectly. At the moment I am building a build through a scriptbuild_usd.py
having previously indicated that I need a non-monolithic and non-shared assembly by specifying this in the script. Also, additionally, I addedadd_definitions("-DPXR_STATIC")
to the CMakefile. After that, I get the build folder in which I have an assembly with several .dll from boost and .lib library files. I copy this folder to my workspace and add all library files to my project in the standard way and add a define to thePXR_STATIC
project. After that, I copy thebuild\lib\usd
folder to the folder with my application executable file without changing anything. After that, I correctly assemble my code, which works if I use dynamic linking with USD and everything runs correctly. But after trying to create a UsdStage, I get an error while executing the code in the filepxr\usd\ar\resolver.cpp
on the lineTF_VERIFY(availablePrimaryResolvers.back().type == defaultResolverType);
becauseavailablePrimaryResolvers
is empty at this stage. If you can tell me how to properly collect and add USD to the project in the form of a static library, I would be very grateful. I could not find such detailed instructions on the Internet. Also, I assume that my mistake may be due to the fact that I am not correctly linking libraries with the project, perhaps there are any global variables or defines that need to be defined? Thank you in advance for your help!