I would like to bring more awareness to this need via this forum and gather more input and perspectives from the AOUSD community and members.
What is the current take on porting the complexity in the python build script to a Conan recipe and maintain the dependencies (like boost, etc) through that mechanism. Essentially bringing the benefits of a dependency and package manager to OpenUSD, as well as the multi-platform support via that approach.
At this stage, we are wrapping the existing python build script in our own Conan recipe, but this leaves a lot to be desired in terms of the support of the variations found in the build script. It would be great if the OpenUSD community supports a Conan recipe as a first-class deliverable.
+1 for Conan. We are also using Conan with a py wrapper around build script and some additional patches, would be great if in the future USD were added to Conan repository.
Very much in support of Conan. I imagine the current set of possible CMake options would end up as options in conan, such as prmanimagingpython etc…
One challenge you will face (without some extra script), between conan and the current build python script is that the build Python script places all the libraries in the same binary folder as USD and its scripts.
This makes it trivial to launch said scripts, since the library locality means that the application runs as expected (e.g usdView).
With Conan, and the way it works with packages, the contents of those packages typically stays in their respective package folders in the local repository.
You could copy it all into the final USD Package if you wanted, but that does remove a nice feature of a package manager removing duplications…
Alternatively you can write a script to gather and add to LD_LIBRARY_PATH (and other OS’ alternatives) as part of a “bootstrap”.
In other open source projects, I notice that the mismatch in release cadence between the projects, and the various build systems people like means that script updates can be delayed, even when there might be some urgency from the perspective of the build and packaging system user. That can be exacerbated when the project maintainers don’t have direct expertise, and are reliant on iteration with the user, sometimes it can take multiple “try this”, “try that” cycles. This has happened already several times in various ASWF projects, so I’m raising the point from experience
My suggestion is that it could make sense to have a conan build as a separate community project, rather than having it in the OpenUSD repo itself. That would allow the “conan + OpenUSD” community to react quickly.
As an existing example, the vcpkg community maintains a recipe at their repo. Occasionally they raise issues at OpenUSD, typically along the nature of “can you add some explicit includes here?”, but the OpenUSD project itself doesn’t take responsibility for maintaining the vcpkg recipe.
I created my own recipe for OpenUSD for learning purposes, but I see someone is already working on getting theirs into Conan Center. That one probably is better since mine only works on Linux, but I’ll release it anyways in case someone finds it useful:
But a word of warning: I encountered some scary runtime crashes (when testing my delegate in usdview) while using it to try and make a render delegate, but didn’t track down exactly what the issue was. I suspect it had something to do with onetbb malloc, and either materialx or hydra. Conan center doesn’t have all the exact versions that the openusd test machines have, so I had to choose substitutes and it’s possible that contributed (or caused) the problem. The problem is gone on my end, but since I never tracked it down, it still scares me…
Either way, proceed with caution. FWIW I ran the openusd test suite with it, and encountered ~17 failures mostly in usdMtlx. I then tried to run the test suite using a regular build_usd.py build, and encountered even more issues! So it could also be a problem with my system.
