How to really use multiproject ?

Pablo J. Rogina

@AnneRanch said in How to really use multiproject ?:

BTW still no answer to my original post

Based on the way you behaved in this post, I'd bet the answer is going to take a long time...

Anonymous_Banned275

@Pl45m4 said in How to really use multiproject ?:

@AnneRanch

See this topic, esp. @t3685 's reply.
https://forum.qt.io/topic/58180/solved-create-top-level-qt-project-to-build-multiple-projects/10

Other links:

https://doc.qt.io/qtcreator/creator-project-creating.html#adding-subprojects-to-projects

https://doc.qt.io/qt-5/qmake-variable-reference.html#subdirs

If you have really huge projects with a more complex structure, it's recommended to use CMake instead of QMake.

Another post recently linked back to this one, so I wanted to augment this with a couple more relevant links for setting up a manageable, maintainable qmake SUBDIRS structure:

https://www.toptal.com/qt/vital-guide-qmake

https://wiki.qt.io/QMake-top-level-srcdir-and-builddir

Which helped me set up a working example: https://github.com/219-design/qt-qml-project-template-with-ci/blob/6af6488d74e1dc97a/main_gui.pro

The above is the "closest" example of implementing "SUBDIRS" with "main project" , but it is little too complex to gain understanding how to implement such setting.

Most examples / tutorials are about the concept of "SUBDIRS" . In my interpretation the "SUBDIRS" is basically way to manage independent projects, sort off "under one roof".
However to actually run such scheme is another and still unclear story.

Looks as intimate understanding of "make" would help.
Maybe the answer is in ".depends" setting of the main .pro.
Cheers

Anonymous_Banned275

This is a REAL C question , but since the discussion is now here I am posting it here.

Update:
As of now my main project is "example MDI".
So I am taking this route hoping to find a solution to the issue.
It is sort of "do not reinvent the wheel" approach.

The MDI example has the attached piece of code which uses QApplication to show text dialog. The link to QApplicatio is still under investigation - all I know it is "external" to "MDI project ".

I figure if I can actually trace the code flow all the way to the message text I could replicate similar approach and replace QApplication with btscanner.

I need assistance with

How do I trace / debug all the way to the QApplication source code (?) which contains the message text ? I am presently stuck at the aboutQt function.
Am I on right track to trace the "addAction" call or is not going to help with btscanner ? ( I feel my current approach is sort of "starting in the middle ". )

Code snippet from "MDI example"

QAction *aboutQtAct = helpMenu->addAction(tr("About &Qt (link to other projets?) "),
         qApp, &QApplication::aboutQt); // shows text dialog "about Qt " 
aboutQtAct->setStatusTip(tr("Show the Qt library's About box"));

Anonymous_Banned275

I will back-off a little.
Can somebody explain (to me ) why the SUBDIRS "directories " AKA independent programs has to be "in sequence "?

Each program basically follow the Qt "Application" scheme - from TEMPLATE to TARGET.

So far I have not found how these dependent programs - each one with its own "main" and QApplication "callback / event" loop can run as one program.
Logically there should be one and only one "main " and its callback / event loop.
Maybe the idea of independent programs supporting ONE main program is bogus. Perhaps there should be ONE main program supported by libraries , not independent programs. (Similar scheme works perfect in another IDE - BUT it has no GUI nor events support !) .
Then the whole scheme of SUBDIRS as "independent programs" is wrong.

JKSH

@AnneRanch said in How to really use multiproject ?:

Logically there should be one and only one "main " and its callback / event loop.
Maybe the idea of independent programs supporting ONE main program is bogus. Perhaps there should be ONE main program supported by libraries , not independent programs....

Then the whole scheme of SUBDIRS as "independent programs" is wrong.

This is correct.

SUBDIRS is for grouping one or more libraries with one application (or no application)

I have not found how these dependent programs - each one with its own "main" and QApplication "callback / event" loop can run as one program.

This is impossible. You cannot have multiple main() and QApplication instances in the same program.

Anonymous_Banned275

@JKSH
So it is back to terminology or semantics.

"project" as used in Qt terminology, especially in "SUBDIRS" scheme is not necessarily code build as a stand alone functioning application.

"library" on the other hand is build / complied as a code to be used to support a "project". Library is NOT standalone functioning application.

With that in mind - SUBDIRS options to "add new project " or add "existing projects " is grossly misleading.

However, the example "MDI" application APPEARS to combine Qt standard QApplication "app" with a reference to another "QApplication " qapp.

Unfortunately this software trick is documented nowhere.
But for sure - "MDI" example source code is nowhere near "SUBDIRS" scheme.

So for time being I am looking into replacing "MDI" QApplication qapp with QApplication "btscaner_app" ( no "main" event loop ) as used in "MDI" example .

Does this makes any sense ?

JKSH

@AnneRanch said in How to really use multiproject ?:

"project" as used in Qt terminology, especially in "SUBDIRS" scheme is not necessarily code build as a stand alone functioning application.

Correct. "Project" is a broad term. For example, you can have an "application project" (which lets you build a standalone functioning application) or a "library project" (which lets you build a library).

Here are some different types of projects: https://doc.qt.io/qt-5//qmake-common-projects.html

Library is NOT standalone functioning application.

Correct. And this is not Qt-specific: The word "library" means something quite specific to programmers, no matter what programming language they use: https://en.wikipedia.org/wiki/Library_(computing)

Qt is a collection of libraries
Qt Creator is a standalone functioning application

With that in mind - SUBDIRS options to "add new project " or add "existing projects " is grossly misleading.

How so? For example, I can add 1 application project and 3 library projects to my SUBDIRS project. What's misleading about that?

However, the example "MDI" application APPEARS to combine Qt standard QApplication "app" with a reference to another "QApplication " qapp.

Sorry, I don't understand what you mean. Can you please elaborate?

Pl45m4

@AnneRanch said in How to really use multiproject ?:

However, the example "MDI" application APPEARS to combine Qt standard QApplication "app" with a reference to another "QApplication " qapp.

Are you confused because of QApplication and QCoreApplicaton?

    QApplication app(argc, argv);
    QCoreApplication::setApplicationName("MDI Example");
    QCoreApplication::setOrganizationName("QtProject");
    QCoreApplication::setApplicationVersion(QT_VERSION_STR);

(https://code.qt.io/cgit/qt/qtbase.git/tree/examples/widgets/mainwindows/mdi/main.cpp?h=5.15#n61)

It's the same, just a bit further down in inheritance tree...
If you look at this, you can see that

QApplication inherits
- QGuiApplication which inherits
  - QCoreApplication

(bottom to top)

So it's still the same instance of qApp.

SGaist

@JKSH said in How to really use multiproject ?:

SUBDIRS is for grouping one or more libraries with one application (or no application)

Just a small addition, you may as well have several applications built using the SUBDIRS model. They will each be independent application. That is useful when you create a suite of applications working together. Like for example a main application plus some helper tools.

One example of SUBDIRS project: Qt itself up to Qt 6 before they switched to the cmake build system.

You have there an example with lots of libraries and executables plus tests.

Anonymous_Banned275

Yes, I did not realize QApplication is the " lead dog" , did not pay attention to inheritance.
Here is my "confusion point" :

// originally last entry Help menu
QMenu *helpMenu = menuBar()->addMenu(tr("&Help")); //TOK

// this enables to print "local" dialog / message - no issue here

QAction *aboutAct = helpMenu->addAction(tr("&About"), this, &MainWindow::about);
aboutAct->setStatusTip(tr("Show the application's About box"));

//TODO link to other projects ?? HERE ??

// #define qApp (static_cast<QApplication *>(QCoreApplication::instance()))
// the above "passes control to "qApp" which actually prints simple text dialog

// can I use same scheme and in my case pass control to "btscanner" btscanner_App. ?

*#define btscanner_App (static_cast<QApplication >(QCoreApplication::instance())) ??? so how do I specify btscanner application here ??

QAction *aboutQtAct =
helpMenu->addAction(tr("About &Qt (link to other projets?) "), qApp, &QApplication::aboutQt); 
aboutQtAct->setStatusTip(tr("Show the Qt library's About box"));

//#endif

Similar post was here :
https://forum.qt.io/topic/72909/is-about-qt-dialog-html-or-text-content-available-in-qt5-api

But then they asked HOW to access the Qt about box/ dialog.
I am asking how to use similar method to pass control from "MDI" to "btscanner" application. in "SUBDIRS" scheme.

What I am asking is
**an expiation about the "#define qApp" usage in "MDI" to access "About Qt" application - not the actual access to the "about Qt" .

JKSH

@SGaist said in How to really use multiproject ?:

@JKSH said in How to really use multiproject ?:

SUBDIRS is for grouping one or more libraries with one application (or no application)

Just a small addition, you may as well have several applications built using the SUBDIRS model. They will each be independent application. That is useful when you create a suite of applications working together. Like for example a main application plus some helper tools.

Right, thanks. You can use a SUBDIRS project to build multiple standalone applications -- but not link them together into a single application.

JKSH

@AnneRanch said in How to really use multiproject ?:
// #define qApp (static_cast<QApplication *>(QCoreApplication::instance()))

// the above "passes control to "qApp" which actually prints simple text dialog

This is wrong. The above shows you definition of qApp. qApp simply gives you a pointer to your program's QApplication object.

Here is one way to use the pointer:

QApplication *myProgram = qApp;
myProgram->quit();

// can I use same scheme and in my case pass control to "btscanner" btscanner_App. ?

*#define btscanner_App (static_cast<QApplication >(QCoreApplication::instance())) ???

No.

You cannot use a #define or a pointer to "link to" other standalone applications. For that, you need to use some form of Inter-Process Communication (IPC).

Anonymous_Banned275

@JKSH said in How to really use multiproject ?:

@AnneRanch said in How to really use multiproject ?:
// #define qApp (static_cast<QApplication *>(QCoreApplication::instance()))

// the above "passes control to "qApp" which actually prints simple text dialog

This is wrong. The above shows you definition of qApp. qApp simply gives you a pointer to your program's QApplication object.

Here is one way to use the pointer:
QApplication *myProgram = qApp;
myProgram->quit();
// can I use same scheme and in my case pass control to "btscanner" btscanner_App. ?

*#define btscanner_App (static_cast<QApplication >(QCoreApplication::instance())) ???

No.

You cannot use a #define or a pointer to "link to" other standalone applications. For that, you need to use some form of Inter-Process Communication (IPC).

The define functions/ works in MDI example and eventually "runs" (addAction) application "about Qt".

I am trying to "trace" and understand "addAction" which seems to be similar to "connect" . BUT no UI ! I do not see why I cannot use same scheme to run my application - "btscanner" as "MDI" menu option.

I am still working on linking SUDIRS "projects" as "applications".

aboutQtAct =
helpMenu->addAction(tr("About &Qt (orignal link to project About Qt ) "),
                    qApp, &QApplication::aboutQt);