I’m looking into removing the moduleDeps.cpp from pxr modules and wanted to get an understanding of how that would impact other developers. Right now, this file is hand-authored and listed in the CMakeLists.txt, but we’re considering removing those files from the source tree and having the build system generate and compile that file automatically instead. This would remove the need for manually updating the moduleDeps. Does anyone have existing libraries that rely on hand-editing moduleDeps.cpp?
Once this change is in, pxr will no longer have or use moduleDeps.cpp files. However, if an external library is built that still has the file, we have the option of using it or ignoring it. Does anyone have a strong preference for either of those options?
When you say that the build system will auto-generate the file, that implies that this file will still exist, and this code will still be built into the libraries, but it will just be generated at build time, right?
In Houdini, we have one moduleDeps.cpp file which I guess we could change over to be generated at Houdini build time. But I’m not sure I see much point, as this file hasn’t changed in 6 years. So if we want to keep using our own moduleDeps.cpp committed to the Houdini baseline, that should be fine, right? Houdini’s build is obviously totally separate from the USD build so we can’t just use the USD build process to generate this file for our own library at build time…
Are the contents of this file going to be different moving forward? If we do decide to auto-generate (either at build time or generate it once and commit the result to our baseline), is there a python script to do this? What would this process look like?
The goal is that the file won’t exist anymore - the code will still get built into the library, but the build system will generate the necessary code and include it in the library directly without creating a file in the source tree.
Houdini moduleDeps.cpp should be totally unaffected! The format of the file shouldn’t change either, so any existing moduleDeps.cpp should continue to work. Since this change is specific to the USD build system, there won’t be an associated python script.