Allow XPMP2 to be built as a shared library

[JeanPhilippeLebel]

Allow XPMP2 to be built as a shared library.

The default behaviour is to build a static library. This is controlled by the XPMP2_BUILD_SHARED_LIBS cmake variable. Set it to ON to build as a static library.

This commit adds the following:

• a new header file (XPMP2Export.h) that controls symbol export.
• A new CMake script to allow find_package(XPlaneSDK) to be used.
• Export symbols were added to some existing .h files.

[TwinFan]

Hi @JeanPhilippeLebel ,

this has been sitting here for a long while. Sorry for my not replying. I'm still not convinced that building XPMP2 as a DLL is a great idea for a library that is being used by a growing number of publicly shipped plugins. Just adding one more file to take care of in the installation process is a disadvantage. And I'm fearing that once somebody starts shipping a DLL version that different versions of it could get into conflict. I'm also not quite seeing the benefit in the build process. But...you may have your reasons, so I was looking into it in recent days.

DLL

As you can see I have decided against merging your Pull Request. Instead, I cherry-picked two of your initial commits and made them the basis for what ended in Pull Request #82 . Look into that if you are interested in what became of it:

• simplified XPMPExport.h to what is needed.
• added XPMP2_EXPORT to a few more places, and removed it from some deprecated functions
• added Github Actions code to build and return a DLL
• took over the idea of the cmake/FindXPlaneSDK.cmake file, though with fundamental changes: It works with "components" now as in many build situations you are not actually needing to link against the SDK, and the XPMP2 doesn't need XPWidgets at all, so that's all now parameterized by way of "components".
• made additions to allow the DLL version to be built with FMOD support
• added logging info at startup that would tell if it is a DLL or not
• added an XPMP2.rc file so that the DLL comes with proper attributes, including version number
• added the version number to the actual DLL file name to reduce risk of version conflict

Official documentation will only get updated once this versions makes it to master branch in a few days, but you can see my build documentation for the DLL already in the next branch. It starts with a big warning...

The code is by now merged into the next branch, which you could try to see if it works for you. Will become official master in a few days as a few more changes are in the pipeline.

Other Changes

One more commit had been added to the Pull Request, which changes other aspects of XPMP2. They look more like "private" changes for your particular use case, but as they ended up in this PR I couldn't pull the PR as I could not agree with those changes in a public library.

Here is what you could do to revert back to official XPMP2 and still achieve your goals:

Color of Aircraft Labels

Your change to 2D.cpp effectively sets the same color for all aircraft labels. XPMP2 allows, however, that every aircraft defines its label color individually. That I certainly want to retain.

If you don't like the standard yellow, then overwrite XPMP2::Aircraft::colLabel in the constructor of your aircraft class (that derives from XPMP2::Aircraft).

Hot Key

I believe a library should not define hard-coded hotkeys. It could even fail if several plugins, using XPMP2, run in parallel. And that happens to a number of users. I don't even believe a plugin should define a hard-coded hotkey.

The better soluton is that the plugin offers the functionality via a "command" and that way allows the user to define a keyboard shortcut or even a joystick button to trigger it in X-Plane's configuration. Check out XPLMCreateCommand, or XPLMAppendMenuItemWithCommand, and XPLMRegisterCommandHandler.

Additional Configuration

The XPMP2.prf config file is a measure of last resort for complex network installations and is missing in the vast majority of XPMP2 use cases. It shall handle networking stuff only.

You should have a way of configuring your plugin, either by UI or by it having a configuration file.

What you tried to configure can then be set from the plugin code as follows:

• maxLabelDist and bLabelCutOffAtVisibility: Call XPMPSetAircraftLabelDist.
• labelFontScaling is not actually used...I should remove this.
• labelColor: as discussed above: this is per aircraft instance
• bLogMdlMatch is exposed as callback configuration item XPMP_CFG_ITM_MODELMATCHING. Provide a callback as 3rd parameter to XPMPMultiplayerInit and in the callback handle that item. XPMP2-Sample demonstrates this here.

[JeanPhilippeLebel]

Hello TwinFan,

Thanks and sorry at the same time.

Some of the changes (well, the last commit) were proposed by collaborator from MIT so I don't want to take for those. Good news if you found value in this. The "sorry" part is that this should have been a separate PR!

One argument for supporting DLL is allow a third party integrator to update the DLL on its own.

I will test the new package later this week.

Good work!