-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add installation of MuJoCo plugins as part of CMake installation logic #1515
base: main
Are you sure you want to change the base?
Conversation
@@ -79,6 +79,30 @@ else() | |||
endif() | |||
|
|||
option(MUJOCO_BUILD_MACOS_FRAMEWORKS "Build libraries as macOS Frameworks" OFF) | |||
option(MUJOCO_INSTALL_PLUGINS "Install MuJoCo plugins" ON) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mind making exactly the same changes to SimulateOptions.cmake?
SimulateOptions.cmake is used for SIMULATE_STANDALONE here:
mujoco/simulate/CMakeLists.txt
Line 60 in 9119239
include(SimulateOptions) |
and the two files should be kept in sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, done and rebased.
Just an OT curiosity, if the two files must be kept in sync, there is any reason why we can't use the same MujocoOptions.cmake
directly in mujoco/simulate/CMakeLists.txt
, for example using include(../cmake/MujocoOptions.cmake)
instead of include(SimulateOptions)
? Indeed inclusion of a file in a sibling directory is a bit ugly, but perhaps it would be easier to manage then two files that need to be manually kept in sync (unless you have something on the Google side to keep them in sync, in that case probably the problem is just for external contributors).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Internally they are just one file that gets split in our CI so ya, this is a problem we save specifically for external contributors 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Annoyingly it looks like copybara still refuses to ingest this 😠
@nimrod-gileadi should I just copy-paste this into a CL?
Alternatively we could implement @traversaro's proposal to do the file duplication/referencing in cmake rather than copybara?
I'll approve yet again, maybe it'll work... 🤷♂️
29c7256
to
603ae79
Compare
I'm back at work now. Will see if we can finally get this merged. |
Some users in my lab found confusing the fact that
simulate
did not found the plugins out of the box if mujoco was built from source, and apparently also other users had the same confusion (see for example #723 (comment)).This PR hopefully simplifies this by also installing as part of the CMake install step the mujoco plugins in
${CMAKE_INSTALL_PREFIX}/bin/mujoco_plugin
, exactly wheresimulate
expects to find them, and where they are placed in the official release binaries.At the moment, I did not include this modifications for the case in which
MUJOCO_BUILD_MACOS_FRAMEWORKS
isON
, as it is not really clear to me how this should be handled. However, when building by sourceMUJOCO_BUILD_MACOS_FRAMEWORKS
is set toOFF
, so for all users that build from source, this PR ensure that the installedsimulate
will be able to find all the mujoco plugins out of the box.fyi @francesco-romano