Hi and welcome to devnet,

To your last question, yes you should move to CMake. There have been new features added in Qt 6 that will likely be of use for your project but that are only available through cmake.

As for examples... maybe check some of the KDE's core projects. They already use CMake and some mix QML and C++.

@rtavakko I'm so pleased to hear the working solution! Thanks for sharing the good news :)

@SGaist Thank you so much for the quick reply.
I finally managed to do it.

If the header is enough, then AFAIK, yes.

@jsulm
got it got it . Thanks .

@fem_dev said in Build with mingw32-make *very* slow:

First Question

Qt Creator starts to use jom, but I got this compile time errors:

09:35:09: The process "C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe" exited normally. 09:35:09: Starting: "C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe" -j4 jom 1.1.3 - empower your colors cd App / && (test -e Makefile || C: /Qt/5.15.0/mingw81_64/bin/qmake.exe -o Makefile C: /Users/VM/Desktop/rotortest/App/App.pro -spec win32- g ++ CONFIG + = debug CONFIG + = qml_debug) && C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe -f Makefile C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe -f Makefile.Debug 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/app.ui -o ui_app.h The syntax of the file name, directory name, or volume label is incorrect. jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_app.h] Error 1 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/custom_widget/value_unit.ui -o ui_value_unit.h 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/form/form_assembly.ui -o ui_form_assembly.h 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/form/form_excitation.ui -o ui_form_excitation.h The syntax of the file name, directory name, or volume label is incorrect. The syntax of the file name, directory name, or volume label is incorrect. jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_form_assembly.h] Error 1 jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_value_unit.h] Error 1 The syntax of the file name, directory name, or volume label is incorrect. jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_form_excitation.h] Error 1 jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile [debug] Error 2 jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ Makefile [sub-App-make_first] Error 2 09:35:10: The process "C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe" exited with code 2. Error while building / deploying project rotortest (kit: Desktop Qt 5.15.0 MinGW 64-bit) When executing step "Make"

How can I fix it?

My system:

Qt Creator 4.12.4 (GCC based - downloaded by MSYS2) Qt 5.15.0 Windows 10 x64 Mingw-w64 jom

Should be completely irrelevant. When your make file works with mingw-make, it has to work with jom as well. jomis a replacement for nmake because it did not allow -j parameter. AFAIK the MSVC does support directly multi-threading and it is not done through nmake.

Besides possible side effects through parallel access to the same file or whatever, there is no difference for compilation. You are listing compile errors which are due to the compiler you are using.

Second question

@koahnig said in Build with mingw32-make *very* slow:

Mingw-make does support now multi-threading. I did some tests back then, but after a reinstall, there was no need anymore.

Are you saying that you compiled your Qt project using the default MSYS2 Mingw-64 configuration (WITHOUT jom) and got a close time compilation speed compared with MSVC 2019?

Nope. I do not use MSVC 2019 compiler at all. AFAIK there was an issue with an older MinGW-make not suporting multi-threading. Therefore this discussion and the solution with jom. After my reinstall I did not bother to set up jom again. At day's end some gain is possible by switching to jom, but it was not enough to go through the hassle again.

You seem to use a self-compiled Qt creator version. The output shows strange blanks around the backslashes. Possibly there is your problem with compilation.

My bad ! It was .qmake.conf that you can use for your common variables.

You can set Project A.3 (subdirs) to depend on Project A.1 (subdirs) of course this create a problem if Project A.1.2 (app) depends on Project A.3.1 (lib)

That I understood. That's why I think that QDirIterator is a better tool to find what you want on your drive.

Modifying the .pro file from the outside is not the correct idea. Since you only want to increment the build number you can mix both. VERSION from the pro file and build number generator that you can take inspiration from here

@TioRoy
Na verdade, quando eu digo "arquivos avulsos" eu me refiro a arquivos de código. Exemplo, Add New...>>Files and Classes não é possível em subdirs somente em projects.

Minha ideia é a da imagem em anexo aqui
Ou seja, funcionario e tecnico são projetos do tipo static lib. Assim sendo cada classe da modelagem UML que representa um objeto na regra de negocio será uma biblioteca estática.
Não sei se essa é a melhor abordagem.

@alexvplay Ok, you were right. I had to add the librarys with LIBS +=.
I think this should be descibed better in the documentation.

I'm not sure if I should open a new thread or not, since it's related but not the same argument.

Anyway, with the project structure above It works fine. But everytime I make a change in a file, and I run single subproject, Qt creator will actually recompile all the subprojects opened, even if I don't need the other units. This takes a lot more time than compiling a single unit and it's frustrating.

How can I tell Qt Creator to compile a single "unit" instead of all the projects?
EDIT
Ok, so, it doesn't always compile all the units. It only does so when I Run the unit.
But still, how can I stop it from doing that? My project is not very large now, but it will grow significantly in time... I can't imagine waiting for it to recompile 10 big units before I get a single run...