# Plugins depending on other plugins problem
**URL:** https://discourse.paraview.org/t/plugins-depending-on-other-plugins-problem/2901
**Category:** Development
**Created:** [November 4, 2019, 5:22pm UTC](https://discourse.paraview.org/t/plugins-depending-on-other-plugins-problem/2901 "2019-11-04T17:22:19Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [November 4, 2019, 5:22pm UTC](https://discourse.paraview.org/t/plugins-depending-on-other-plugins-problem/2901/1 "2019-11-04T17:22:19Z")
This is a problem that I currently did not expect - because so far it worked for me! But I did some renaming, and that might have caused the issue to appear now.
Some of my plugins are derived from some others from my own project. Meaning that their “modules” (which is the actual C++ source code) depends on the “modules” of their “parents” - in order to #include the header and derive the class. As a consequence I put the parent modules into the DEPENDS section of the vtk.module file of the child plugin modules, because only with that I can do the proper #include in the C++ headers.
But now I am getting complaints from ParaViewPlugin.cmake:581: “Failed to find the required module …” - meaning: the module from the parent plugin. This is from the paraview\_add\_plugin function that wants to build it’s modules and make sure that modules on which it depends do exist. Well - they come later in the list, so they are not built at that moment yet…
So I went for another solution: from the call to paraview\_plugin\_scan I am getting the names of the modules that are required by the plugins, so I can simply filter out those that are from my own project and build them explicitly before I do the paraview\_add\_plugin call. With that they should exist when they are required!
But now I am getting another error message from vtkModule.cmake(2079): “The … module has been requested to be built, but it is already built by this project”. This is from the vtk\_module\_build function which in turn is automatically called by paraview\_add\_plugin, trying to build the plugin module. But yes - it was already built in order to satisfy some other plugin!
Ok - this is a bit circular in my eyes…
I think I will do now the following - as kind of a workaround: after having the list of plugins from the paraview\_plugin\_scan function, I will analyze that list and sort it somehow in a way that plugins that are needed by others are first and the others later. A little bit “hackish” in my eyes, but I guess that in my case I will manage like that: it is basically four plugins that have to be ensured that they come in front of all others.
However, a more thorough solution should in my eyes avoid the above circle, by either allowing plugins to depend on modules that are not built yet. Ok, this can generate a problem later on. Or simply not building plugin modules that are already built - instead of complaining: the modules are there - what else do we want?
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [November 4, 2019, 7:23pm UTC](https://discourse.paraview.org/t/plugins-depending-on-other-plugins-problem/2901/2 "2019-11-04T19:23:34Z")
If a module is to be used by more than one plugin, I highly suggest moving it out of the scope of plugins and into the main build. It is obviously more general than code for a specific plugin at that point.
---
### Author:  [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [November 5, 2019, 8:53am UTC](https://discourse.paraview.org/t/plugins-depending-on-other-plugins-problem/2901/3 "2019-11-05T08:53:07Z")
That makes sense - and I would also like the idea to “loosen” the 1:1 relationship between plugins and modules in my project! However, there were so many things where I struggled in the beginning because I did not understand them yet that finally this 1:1 relation was the only thing that I finally got working.
One very basic thing was the fact that I have somehow two types of VTK modules in a PV project: 1) those that I call “standalone modules” and 2) those that I call “plugin modules” because they are directly related to a plugin. Which basically only makes the following CMakeLists.txt setup logical:
1. paraview\_plugin\_find\_plugins and paraview\_plugin\_scan - finding modules that are required by plugins, but EXCLUDING the plugin modules
2. vtk\_module\_find\_modules and vtk\_module\_scan - more or less just check if required standalone modules can be built
3. vtk\_module\_build - but ONLY for the standalone modules
4. paraview\_plugin\_build - for building the plugins, but ALSO automatically the plugin modules
Also now I added another step between 3 and 4, checking the “plugin required modules” if there names actually match with plugins, and simply put these plugins first in the plugin list for step 4. Of course this would not work any more with more complex interrelationships, but at the moment it is ok
I think if I had understood this from the beginning, I would have separeted plugins and modules much more - putting a lot of code into modules and realize many plugins only with an XML file, referring to classes that are inside some standalone modules. But basically I did not understand the difference between these two types of modules, so when I e.g. tried to refer in the paraview\_add\_plugin call (which is indirectly called through the paraview\_build\_plugin) to a module that was also already used by another plugin - I got these error messages about “module already built” that I had also yesterday.
With the huge difference that now I understood the logic of the two module types, while in the beginning of my project this was the reason that triggered me to entirely restructure my project again - avoiding any common use of modules between plugins.
You could also say that I did not understand the “hidden vtk\_module\_build” inside the plugin building logic.
But still today I do not understand why this hidden call should generate an error if somebody tries to refer to a module from several plugins: In my eyes should the fact that a module already exists not trigger an error message, but simply not build it once more, so using the existing module once more.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [November 9, 2019, 5:12am UTC](https://discourse.paraview.org/t/plugins-depending-on-other-plugins-problem/2901/4 "2019-11-09T05:12:13Z")
> [@cobo](#):
>
> But still today I do not understand why this hidden call should generate an error if somebody tries to refer to a module from several plugins: In my eyes should the fact that a module already exists not trigger an error message, but simply not build it once more, so using the existing module once more.
This way leads to duplicate symbols and spooky runtime linker errors. You don’t want to go there 🙂 . The thing is that two plugins both “claiming” a module causes two client server wrapping setups to run. That also ends up with duplicate symbols and CS binding registration. If you have CS wrappings that need to be leveraged by multiple plugins, I suggest doing something like `pvPluginInitializer` [here](https://gitlab.kitware.com/paraview/paraview/tree/master/ParaViewCore/ServerManager/SMApplication).
Basically, manually wrap your modules using `vtk_module_wrap_client_server` and `paraview_server_manager_process` and link to them in your new “plugin module”. Exclude the module from CS wrapping by using `vtk_module_client_server_exclude()` (it’d be recursive otherwise). Then make a static plugin like [this](https://gitlab.kitware.com/paraview/paraview/blob/master/ParaViewCore/ServerManager/SMApplication/vtkPVInitializer.h) behind a Schwarz counter to prevent duplicate registration. Your plugins can then trigger this plugin load in an `auto_start` interface of their own.