How to break circular dependency between exe and dll-CodePudding

A C app has this exe/dll layout:

Main.exe, Framework.dll, PluginA.dll, PluginB.dll, ..., PluginN.dll

Both Main.exe and Framework.dLL provide functions to the Plugin#.dll.

The Plugins are depedent on Main.exe and Framework.dll, but not the other way around. Framework.dll depends on functions provided by Main.exe

Now, the problem is that there is a circular dependency between Main.exe and Framework.dll because Main.exe depends on 1 class in Framework.dll that it uses to manage the lifecycle of Framework.dll

So, in Main.exe, it would be something like this:

#include "Framework.hpp"

int main() {
    Framework fw;
    fw.Init();
    
    while (Quit() == false) {
        fw.Begin();
        DoWork();
        fw.End();
        MoreWork();
    }
    
    fw.Shutdown();

    return 0;
}

So, Main.exe depends on only 1 class from Framework.dll, but that's enough to create their circular dependency.

Is there a way to still use that one Framework class from Main.exe while still breaking the circular dependency? Specifically, so that Main.exe doesn't require the export library Framework.lib to build.

CodePudding user response：

The usual solution to this (although it's usually used when two libraries have a circular dependency) is to create a 'dummy' version of one of them that defines all the relevant entry points but is not in any way dependent on the other and doesn't need to link against it. That can then be used as a kind of 'bootstrap'.

So in your case, you might create yourself a dummy_framework.cpp file that you can build to provide a framework.lib that main can then link against. Once you've done that, you can compile the 'real' framework to generate the 'real' framework.dll and you should then have a fully functional version of your app. (You can rebuild main if you want, but there shouldn't actually be any need.)

This is all perfectly viable so long as the API of framework is reasonably stable, but even if it isn't, you'll get compiler or (more likely) linker errors when you try to build dummy_framework so you can update it then.