Adding cmake options to toggle building / skipping vehicle-specific plugins?

[Hs293Go]

A make px4_sitl gazebo call in a fresh PX4 repo takes around 2 to 3 minutes, and I always find myself commenting out some plugins that clearly correspond to specific PX4 build variants that are mutually orthogonal. Such as

gazebo_uuv_plugin              => make px4_sitl gazebo_uuv_hippocampus
gazebo_catapult_plugin         => make px4_sitl gazebo_plane_catapult
gazebo_usv_dynamics_plugin     => make px4_sitl gazebo_boat
gazebo_parachute_plugin        => make px4_sitl gazebo_if750a
gazebo_airship_dynamics_plugin => make px4_sitl gazebo_cloudship
gazebo_drop_plugin             => make px4_sitl gazebo_standard_vtol_drop (undocumented on the PX4 user guide)

For the simplest make px4_sitl gazebo, all of these plugins are built by default, whereas from my subjective experience if I manually disable these plugins, build time is reduced by about. 10% on my XPS-15 9570.

I imagine adding cmake options to enable these plugins, that can be toggled for specific build variants inside sitl_targets_gazebo.cmake, could help cut down the build overhead and improve the development experience.

I'm willing to code this up and submit a PR, but I'd like to create an issue and ask for opinions first, in case any contributor strongly believes their plugin should be built by default, at all times.

[Jaeyoung-Lim]

@Hs293Go Sounds like a good idea, but a little concerned about the complexity introduced by it when trying to document and maintain the different build combinations that would be introduced

[Hs293Go]

@Jaeyoung-Lim Well, your concern is why I'm NOT proposing toggling building sensor plugins (even though I routinely disable sensor plugins as well). Since mixing sensor combinations actually happen.

But vehicle plugins map one-to-one to vehicle builds, e.g. gazebo_uuv_plugin will never be combined with gazebo_drop_plugin in one build, so I think this bypasses the combinatorial explosion of build combinations

[Jaeyoung-Lim]

But vehicle plugins map one-to-one to vehicle builds, e.g. gazebo_uuv_plugin will never be combined with gazebo_drop_plugin in one build, so I think this bypasses the combinatorial explosion of build combinations

I agree with the general idea and benefits, I just don't see how we can maintain the dependencies. If we are to do this, we need to maintain the list of what plugins map to which vehicle, which is no longer part of this repository. While some of the plugins will be clear cut as you described, but a lot of the other sensors boundaries are quite gray in my opinion.

I don't see a straight forward path how we can manage this dependency without accidentally having partially broken models.