Kategorie: Meine Tools

[:de]Dieser Artikel präsentiert die Details zu Plugin-Plugin-Abhängigkeiten in MegaMol™. Als Hauptszenario nutzt ein Plugin (oder mehrere) exportierte Call-Klassen eine anderen Plugins (und nicht des MegaMol™-Cores).

Tatsächlich wurde am MegaMol™-Core nichts geändert. Die Plugin-Plugin-Abhängigkeiten funktionierten bereits größtenteils. Die Einschränkungen und im Besonderen die Probleme im Fehlerfall sind unten beschrieben.

Testproject: interplugin_test

Dieses Projekt hat zwei Plugins:

https://bitbucket.org/MegaMolDev/megamol_interplugin_test

Plugin A exportiert 2 Module und 1 Call.

Plugin B exportiert ein Modul, welches aber den Call aus Plugin A nutzt.

Export des Call-Header

Normalerweise werden Module und Calls nur über ihrer Metadaten-Description exportiert, als Teil der Implementierung in „plugin_instance“. Diese Metadaten reichen dem MegaMol™-Core um die Module und Calls zur Laufzeit zu instanziieren. Die Klassen selbst werden üblicherweise nicht direkt exportiert.

Wenn wir nun allerdings einen Klasse, einen Call, in einem anderen Plugin zur Compile-Zeit nutzen wollen, dann muss diese Klasse exportiert sein. Zunächst muss der Header der Klasse im Ordner der öffentlichen Header des exportierenden Plugins liegen. Typischerweise sieht das so aus wie im Demoprojekt: „./a/include/interplugin_test_a/IplgDemoCall.h“ Ich empfehle auch die Headerdatei im Visual Studio Solution Explorer in den Filter “Public Header Files” zu legen um hier konsistent zu sein.

Zusätzlich muss die Klasse noch exportiert werden. Das geschieht mit dem API-Macro des Plugins: z. B. „INTERPLUGIN_TEST_A_API”, welches in Haupt-Header des Plugins definiert ist, z. B. „interplugin_test_a/interplugin_test_a.h“

Natürlich müssen die Metadaten-Descriptions des Calls trotzdem nach wie vor in der „plugin_instance“ exportiert werden (vglf. „interplugin_test_a.cpp“ Zeile 51).

Calls in einem anderen Plugin einsetzen

Um den Call nun in einem anderen Plugin zu nutzen muss dieses prinzipiell nur gegen das exportierende Plugin linken. Dem Demoprojekt folgend nennen wir das exportierende Plugin A und das nutzende Plugin B.

Zunächst sind beides einfach nur Bibliotheken, und A ist eine Abhängigkeit für B. Für Visual Studio empfehle ich das Skript „configure.win.pl“ und die Datei „ExtLibs.props.input“ anzupassen, als würde man irgendeine andere Drittherstellerbibliothek hinzufügen. Im Demoprojekt ist der Pfad von Plugin A in „ExtLibs.props.input“ hardgecoded. Anschließend kann das neue User-Macro in den Projekteinstellungen genutzt werden:

• C/C++ > General > Additional Include Directories
  • Z. B. $(PluginAPath)include\
• Linker > General > Additional Library Directories
  • Z. B. $(PluginAPath)lib\$(PlatformName)\$(Configuration)\
• Linker > Input > Additional Dependencies
  • Z. B. interplugin_test_a.lib

Der Linker nutzt nur die Import-Bibliothek von Plugin A, nicht das kompilierte Plugin selbst.

Nun können auch die öffentlichen Header von Plugin A gefunden und Includet werden, vgl. „./b/src/IplgValueInvertB.cpp“ Zeile 3. Plugin B kann nun die exportierte Klasse ganz normal nutzen, wie jede andere Klasse jeder anderen Bibliothek auch. Keine Sonderbehandlung ist notwendig.

Unter Linux könnte man im „CMakeLists.txt“ auch entsprechende Einstellungen einbauen. Ich habe das nicht gemacht.

Ich installiere alles von MegaMol™ beim Bauen in ein lokales Unterverzeichnis in meinem Home (angegeben durch den Install-Prefix bei den Build-Skripten). Dadurch sind alle Teile MegaMols™ an derselben Stelle. Das betrifft natürlich auch den Core, welcher bereits durch das „CMakeLists.txt“ gefunden wird, und auch Plugin A, welches daher versehentlich gefunden wurde. Daher ist der Include-Pfad für die öffentlichen Header des „installierten“ Plugins bereits bekannt. Außerdem ist es unter Linux nicht notwendig Shared Objects gegen ihre Abhängigkeiten zu linken. Das ist Aufgabe des Runtime-Loaders sämtliche Referenzen aufzulösen. Daher sind weitere Einstellungen zum Bauen des Plugins schlicht nicht notwendig.

Wenn Sie trotzdem das exportierende Plugin explizit finden möchten, beispielsweise, weil es nicht installiert sein sollte, dann müssten Sie am sinnvollsten ein entsprechendes CMake-Find-Skript schreiben und in der „CMakeLists.txt“ des abhängigen Plugins „find_package“ nutzen. Zumindest augenblicklich ist mir das aber egal, da das exportierende Plugin sowieso installiert sein muss, damit alles zur Laufzeit funktionieren kann.

MegaMol™ mit beiden Plugins konfigurieren

In der MegaMol™-Konfigurationsdatei müssen beide Plugins ganz normal angegeben werden, entweder explizit mit ihren Namen (empfohlen) oder per File-Globbing. Sie sollten aber die Anhängigkeiten beachten und die Plugins in der richtigen Reihenfolge laden, z. B. Plugin A sollte vor Plugin B geladen werden. Technisch ist es aber egal.

Beide Plugins, alle Plugins, sind im Prinzip nur Dlls. Wird Plugin B zuerst geladen, also die Dll, so werden auch alle abhängigen Dlls geladen. Dabei ist auch die Dll Plugin A dabei welche daher in den Speicher geladen wird. Allerdings sind die Metadaten von Plugin A noch nicht in den Core geladen und seine Module und Calls daher noch nicht zur Laufzeit verfügbar. Wird nun das Kommando ausgeführt um Plugin A zu laden, und das Betriebssystem aufgefordert diese Dll zu laden, so befindet diese sich schon im Hauptspeicher. Anschließend werden die Metadaten in den Core geladen und stehen den Factories zur Verfügung.

Warnung vor zyklischen Abhängigkeiten

Zyklische Abhängigkeiten sollten, wie immer, vermieden werden. In der Theorie sollte es möglich sein zyklische Abhängigkeiten aufzulösen. Allerdings, sollten Sie ihren Code in diese Richtung entwickeln, dann empfehle ich dringend ein weiteres Plugin zu starten in dem Sie alle gemeinsam genutzten Klassen auslagern, z. B. Calls.

Laufzeitverhalten wenn abhängige Plugins nicht gefunden wurden

Die Fehlermeldungen des Betriebssystems wenn eine Dll (Plugin) nicht geladen werden kann sind ziemlich nutzlos. (Ich arbeite hier an Verbesserungen, aber das ist weit nicht so einfach wie man denken würde.) Normalerweise sagt die Fehlermeldung nur, dass die Dll nicht geladen werden konnte. Denken Sie also daran, dass diese Fehlermeldung nun auch kommen kann wenn ein Plugin die Plugins nicht laden kann von denen es selbst abhängt. Die Plugin-Abhängigkeiten müssen also sowohl zur Compile-Zeit als auch zur Laufzeit auflösbar sein. Beides löst sich selbst wenn einfach alle Plugins in den gleichen lokalen Ordner „installiert“ werden.

Versionsnummertests

Alle Plugins prüfen zum Zeitpunkt wenn sie geladen werden die Versionsnummern von Core und Vislib. Damit werden Inkonsistenzen zur Laufzeit verhindert. Stellen Sie sich vor, sie bauen den Core und arbeiten dann an ihrem Plugin. Dabei fällt eine Bugt in der Vislib auf und wird von ihnen gefixt. Core und Plugin würden nun unterschiedliche Vislibs benutzt und nur diese Versionsnummerprüfungen teilen ihnen mit, dass das eine wirklich schlechte Idee ist.

Nun ersetzen Sie in diesem Szenario die Vislib mit Plugin A. Willkommen in der Hölle. Augenblicklich gibt es keinen Mechanismus um Versionsnummer zwischen Plugins zu überprüfen. (Wahrscheinlich kommt auch keiner vor der Implementierung des berüchtigten „Call-Interface-Redesigns“.) Sie müssen einfach aufpassen!

 [:en]This article details the work with inter-plugin dependencies in MegaMol™. The primary scenario is to have one (or many) plugins use Call classes exported by another plugin (and not the MegaMol™ core).

Actually, nothing was changed in the MegaMol™ core. Inter-plugin dependencies already worked, to some extent. The limits, and especially the behavior in error cases are described below.

Test Project: interplugin_test

The following project shows two plugins:

https://bitbucket.org/MegaMolDev/megamol_interplugin_test

Plugin A exports 2 modules and 1 call.

Plugin B exports one module using the call exported by modul A.

Exporting Call Header

Usually, modules and calls are only exported via their meta data description classes as part of the implementation in “plugin_instance”. This meta data is sufficient for the MegaMol™ core to instantiate the module at runtime. However, these classes are normally not exported by the plugins.

If you want to use a class, a Call, in other plugins at compile time, you have to export the type. You need to place the corresponding header file in the public export folder. For a typical case, have a look at the demo project: “./a/include/interplugin_test_a/IplgDemoCall.h” I also recommend to add the header files to the filter “Public Header Files” in the Visual Studio Solution Explorer.

Additionally, you need to export the class using the corresponding API macro: e.g. “INTERPLUGIN_TEST_A_API”, which is defined in the plugin’s primary header file, e.g. “interplugin_test_a/interplugin_test_a.h”

Of course, you still need to export the meta data description for the call itself in the “plugin_instance” definition (cf. “interplugin_test_a.cpp” line 51).

Using Call in another Plugin

Now, to use the Call in another Plugin, that one basically needs to link against the exporting Plugin. Following the demo project, the exporting plugin is called A and the using plugin in named B.

First A is a library and a normal development dependency for B. For Visual Studio, I recommend using the “configure.win.pl” and “ExtLibs.props.input” similar to any other 3rd-party library. In the demo project, the access to the subdirectory of A is hard coded in the “ExtLibs.props.input”. Then, you can use this user macro in the project settings:

• C/C++ > General > Additional Include Directories
  • E.g. $(PluginAPath)include\
• Linker > General > Additional Library Directories
  • E.g. $(PluginAPath)lib\$(PlatformName)\$(Configuration)\
• Linker > Input > Additional Dependencies
  • E.g. interplugin_test_a.lib

As you see, the linker only uses the built input library of the plugin, not the compiled plugin A itself.

Now you can find the public header file of the call exported by the plugin, cf. “./b/src/IplgValueInvertB.cpp” line 3. Plugin B uses this class like any class exported from the core. Nothing special is required.

For Linux you could introduce similar settings in the “CMakeLists.txt” file. I did not.

Since I install everything of MegaMol™ into a local user directory (using the install prefix settings in the build scripts) all parts of MegaMol™ are available at the same location. This includes the core, which the “CMakeLists.txt” file already searches for and Plugin A, which is thus accidentally found too. So the public include files, which were copied when Plugin A was “installed” are already available. Linux does not require shared objects to link against their dependencies. The runtime loader is expected to resolve all issues. Thus, for building on Linux no additional settings are required.

If you want to be able to work with plugins not locally installed, you should write a corresponding find script for the base plugin A and use “find_package” in the “CMakeLists.txt” of plugin B. For now, I don’t care.

Configuring MegaMol™ with both Plugins

Just add both plugins, as usual, to the MegaMol™ configuration file. Either explicitly (recommended) or using file globing. You should keep the dependencies in mind. So you should load plugin A before you load plugin B. But technically, it does not matter.

Both plugins, all plugins, are basically Dlls. So if you load plugin B first, the Dll is loaded with all its dependencies. These include the Dll plugin A. So plugin A is in memory the, but the meta data is not known to the core yet. If then the command for loading plugin A is executed, the OS runtime is asked to load the Dll plugin A. Since that Dll is already in memory, the load succeeds and the plugins meta data is received and added to the core factory constructs.

Beware of Cyclic Dependencies

Cyclic Dependencies should be avoided, as always. In theory, they could work, like Plugin A uses a class from Plugin B and the other way round at the same time. However, if you are going towards such a scenario, I strongly recommend to create a third Plugin holding the shared classes, e.g. Calls.

Runtime Behavior if Dependent Plugin is not found

The OS runtime errors when a Dll (Plugin) cannot be loaded are rather useless. (I am working on something better here, but it is not as easy as one would think.) Usually, it only tells you that the Dll could not be loaded. So keep in mind, if you developing your plugins that other plugins you depend on, not only need to be available at compile time, but also need to be installed in the same bin directory for runtime access.

Version Number Tests

All plugins check their version numbers of Core and Vislib with the loading core. This is to avoid inconstancies at runtime. Imagine you build the Core, then work on your Plugin. In this work you stumble upon a bug in the Vislib and fix that. Then your core and your plugin use different Vislibs and only this very version check tells you that this is a bad idea.

Now, use that scenario and replace Vislib with plugin A. Welcome to hell. There currently is not version check implemented for cross-plugin dependencies. (Most likely, there will be no such check before the infamous coming “Call Interface Redesign”.) You need to be careful![:]