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.
I'm glad everything worked out! Good note on /wholearchive!