jwnimmer-tri
commented
9 months ago I'll post here some info I've gathered on the build system front. As I learn more, I'll probably circle back and edit the summary in this post, as well as the original post.
One aspect of building OpenUSD is to identify any required dependencies, and any optional dependencies that we would like to opt-in to.
We need to check the licenses of those dependencies, and how to integrate them into our build. On first skim, all of the licensing questions will be easy (the licenses are unremarkable) and the only question on that front will be ensuring that we properly redistribute all of the notice texts.
The main question will be integrating OpenUSD and its dependencies the build system.
Some of the dependencies are already vendored:
OpenUSD/pxr/base/js/rapidjsonOpenUSD/pxr/base/tf/pxrDoubleConversionOpenUSD/pxr/base/tf/pxrLZ4- etc
For these, we just need to be sure to obey ODR -- if we have another copy of the library in Drake, we either need to unify them in the workspace, or else ensure that their names will not conflict. For example in the case of pxrDoubleConversion the OpenUSD code has already patched in their own custom namespace, and so it would not conflict with our VTK copy of double-conversion (which is also wrapped in a custom namespace).
One required, non-vendored dependency is libtbb.
We already link a copy of libtbb as part of our MOSEK integration. I'm inclined to use the MOSEK version of TBB even in our non-MOSEK builds. I think it would simplify testing to always pin a single version, instead of different versions depending on build flags.
Another required, non-vendored dependency is boost.
It's a little tricky to figure out the exact subset of boost that is required (because the OpenUSD code mixes the Python bindings next to the non-Python sources, so I'm not sure exactly which OpenUSD files we need in Drake), but as a first approximation I'm seeing:
$ find OpenUSD/pxr/base OpenUSD/pxr/usd -name testenv -prune -o -name plugin -prune -o -name 'py*' -prune -o -name 'wrap*' -prune -o -name 'module.cpp' -prune -o -name '*Module*' -prune -o -name '*Py*' -prune -o -name 'pch.h' -prune -o -name '*.dox' -prune -o -type f -exec grep -h -e '#include.*<boost' \{\} + | sort -u
#include <boost/any.hpp>
#include <boost/intrusive_ptr.hpp>
#include <boost/multi_index_container.hpp>
#include <boost/multi_index/hashed_index.hpp>
#include <boost/multi_index/identity.hpp>
#include <boost/none.hpp>
#include <boost/numeric/conversion/cast.hpp>
#include <boost/optional.hpp>
#include <boost/optional/optional_fwd.hpp>
#include <boost/preprocessor/...lots...>
#include <boost/ptr_container/ptr_set.hpp>
#include <boost/smart_ptr/intrusive_ptr.hpp>
#include <boost/utility.hpp>
#include <boost/variant.hpp>
#include <boost/vmd/is_empty.hpp>Drake has a policy of not using Boost, because of ABI conflicts with other libraries that users might want to use that also use Boost, but of a different version.
That doesn't matter for things like BOOST_PP macros which evaporate in the object code, but will matter for anything with linkage.
Possibly we could use BCP to re-namespace the subset of Boost that we need for OpenUSD.
There are some heros trying to de-boostify OpenUSD with pull requests; possibly we could pour our fuel on that fire instead of working around the problem. TBD.
sherm1
This is a sub-task of #17833.
I'm filing it separately because it will involve a non-trivial amount of details that are mostly unrelated to the multibody and parsing side of Drake.
The call to action is to be able to run a unit test inside Drake that loads some minimal
*.usdfile by calling into OpenUSD and call some various accessor functions that interrogate the loaded scene. Basically a "proof of life" that we've successfully linked to a copy of OpenUSD can be run without crashing./tmp:Writing stack for smoke_test to /tmp/st_smoke_test.rl8KNi because of ERROR.boost_internalexternal (rmcommit_pin = True)~