Skip to content

Comments

Fix plugin loading in simulate UI#3089

Open
Ashutosh0x wants to merge 2 commits intogoogle-deepmind:mainfrom
Ashutosh0x:fix/plugin-install-paths
Open

Fix plugin loading in simulate UI#3089
Ashutosh0x wants to merge 2 commits intogoogle-deepmind:mainfrom
Ashutosh0x:fix/plugin-install-paths

Conversation

@Ashutosh0x
Copy link
Contributor

@Ashutosh0x Ashutosh0x commented Feb 11, 2026

This Pull Request fixes an issue where MuJoCo plugins (SDF, elasticity, sensor, etc.) were not being loaded by the simulate executable when building from source or installing.

The Problem

The simulate executable looks for plugins in a mujoco_plugin subdirectory. However, the plugin CMakeLists.txt files were missing install directives and did not set the RUNTIME_OUTPUT_DIRECTORY / LIBRARY_OUTPUT_DIRECTORY, so the plugins were placed in the default bin or lib folders where simulate couldn't find them.

The Fix

Added set_target_properties to set the build-time output directory to bin/mujoco_plugin and added install commands to ensure they are also copied there during installation.

Fixes #3013

Plugins like SDF, elasticity, and sensor were not being correctly copied to the 'mujoco_plugin' subdirectory where the 'simulate' executable looks for them.

This change adds install and output directory directives to the plugin CMakeLists.txt files, ensuring they are placed in the correct location both in the build tree and after installation.

Fixes google-deepmind#3013
This ensures that plugins are installed to a 'mujoco_plugin' subdirectory relative to the 'simulate' executable (which is in 'bin') on Linux and macOS, matching the expectation of the plugin loader logic in 'simulate/main.cc'.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Both internal and external plugins do not get loaded when running simulate executable

1 participant