I haven’t touched C++ project binding to plugins in a while, and I’ve just recently hit the same problem actually with my zip plugin!
I’m going to try your fixes and get back to you, but thanks a lot for the suggestions! If this compiles for you without problems, consider making a pull request to have the changes added to the master branch.
Edit: Back in 4.0 I would copy the class implementation files for editor (where plugins are isolated in their own dlls) and remove them in packaged solutions (your dlls are collapsed into a monolithic build so it would link without issue). So this is much cleaner than that hack.
According to plugin documentation what we’re doing is essentially creating a hard bind, but I believe it falls under
If you are creating a game plugin (not engine plugin), and you want to allow the game to statically link against one of your plugin modules. This breaks the concept of a plugin a little bit, but is often useful for plugins that want to declare new UObject types that game classes can inherit from or use directly. The engine itself has no dependencies on this plugin, but the game project code and content may very well have direct dependencies.
I’m not 100% sure on best practices, but it does seem to be the most convenient and when you want to use leap motion specific methods in C++ there really isn’t a practical way to not use this approach.