Unresolved error when compiling

I have a bit of a problem when compiling my application which complains with an LNK2019: unresolved error.

Code:

---

LNK2019: unresolved external symbol "public: void __thiscall MainWindow::showMessageBox(class QString)

---

Basically my application is split into modules to make it easier to add/remove features and one of those modules cannot 'see' another file.

The project structure is as follows:

Code:

---

Project
---- bin
 
---- modules
---- ---- FooModule
---- ---- ---- FooModule.h
---- ---- ---- FooModule.cpp
 
---- src
---- ---- MainWindow.h
---- ---- MainWindow.cpp

---

The compiled files from both the modules folder and src folder end up in the bin folder after a successful compilation.
FooModule is actually a separate project within the main project folder and is compiled as a shared library (i.e. dll, as I'm on Windows).
MainWindow successfully creates a new FooModule and passes itself into FooModule's constructor.
At this point FooModule knows about MainWindow's header file but can't see the implementation file as when I try to call any of MainWindow's methods from FooModule's constructor I get the unresolved error about the method I just tried to call.

I'm guessing I just haven't quite got the correct info in the .pro files:

Code:

---

// Project.pro
 
QT       += core gui
TARGET = Project
 
TEMPLATE = subdirs
CONFIG += ordered debug
 
SUBDIRS += modules/FooModule \
            src \

---

Code:

---

// FooModule.pro
TARGET = FooModule
TEMPLATE = lib
 
DEFINES += FOOMODULE_LIBRARY
 
SOURCES += FooModule.cpp
 
HEADERS += FooModule.h\
        FooModule_global.h
 
INCLUDEPATH += ../../src
 
DESTDIR += ../../bin

---

Code:

---

// src.pro
QT       += core gui
 
TARGET = Project
 
TEMPLATE = app
 
CONFIG += ordered debug
 
INCLUDEPATH += ../modules/FooModule
 
SOURCES += main.cpp\
        MainWindow.cpp \
 
HEADERS  += MainWindow.h 
 
LIBS += -L../bin -lFooModule
 
DESTDIR += ../bin

---

Can anyone see where I have gone wrong?
Thanks

you have a circular reference. redesign/refactor to remove it.

foomodule should not be needing to know anything about users of itself.

Thanks, yes, I see what you mean now.
I think I've probably got my concepts muddled a little bit, this is the first time I've made and tried to use my own library.
I guess the idea of a library is a self contained unit that knows how to perform a task but has no idea how it gets used in a specific application i.e. like a database library that knows how to connect, open, query etc but it is your specific application that calls those methods.

What my thinking was to create the different modules independently from each other, passing in the Main Window to their constructors, and therefore no module has any knowledge or dependency on any other part of the program (other than the MainWindow). Each module can then look after after itself and update the MainWindow etc. This way, any module can be added or removed with ease.

I think I'm on the right lines but trying to compile each module as a dynamic library was probably the wrong approach. It would have been nice to have been able to complete a module, compile it, and then forget about it and keep the core application lightweight, also not having everything compile (all modules) when I Build or Run. Some of the Run compile times are getting a little silly now.

Thanks again for the help.