How to saving the compling time ?

jsulm

@nicker-player said in How to saving the compling time ?:

It will take a long time only if modified one file,and it seemd to recompile the whole project only if modified one file

This should not happen.
What build system do you use (qmake, CMake,...)?
On what OS and file system?

"By the way,how to using a common variety for the sub .pro files?Like the extern usage of the cplus code." - I don't understand this, please elaborate.

nicker player

ps:
os:windows 7
and qmake
and i used the harddisk of SSD

and that
"By the way,how to using a common variety for the sub .pro files?Like the extern usage of the cplus code." -
means
there are three pro files in the project
base.pro
A.pro
B.pro
base.pro defined some varieties like $$vars and so on
how could the A.pro and B.pro file used the $$vars from the base.pro file?

piervalli

With cmake you can save many time because cache many objects. But it is more complexes of qmake :-(

Christian Ehrlicher

@piervalli said in How to saving the compling time ?:

With cmake you can save many time because cache many objects.

?

Neither cmake configure nor qmake is run when a source or header file is changed.
cmake is only run during compile time (in contrast to qmake) when you enable AUTOMOC, AUTOUIC or AUTORCC but this must be enabled manually in CMakeLists.txt

The most effecitve way to reduce compile times is to avoid including other headers in your own header files since parsing of them takes quite some time. Also moc (esp. on windows) is slowed down by a lot of include statements.
PCH can be a speedup if you have a quite big common set of headers used in every source and the sources are compiled with the same compiler options & definitions.

piervalli

@Christian-Ehrlicher , ok sorry.

JoeCFD

@nicker-player
For example:
define this in your base.pro
THIRD_PARTIES=/opt/thirdParties
then add this in A.pro(normally called A.pri?). You include A.pro in base.pro, right?
message( "======$$THIRD_PARTIES" )
You will see $$THIRD_PARTIES can be used directly.

nicker player

@JoeCFD
Thanks very mush.It helps.
And

qnx: target.path = /tmp/$${TARGET}/bin
else: unix:!android: target.path = /opt/$${TARGET}/bin
!isEmpty(target.path): INSTALLS += target

and what does the code above means?Someone told me that it will copy the files into the bin path ?Is it true?Or howto copy the libraries of the sub project before the major execution was compiled?

SimonSchroeder

@nicker-player said in How to saving the compling time ?:

1.using the preheader for the libraries

What files do you have include in your pre-compiled header? I only use header files from libraries because I know these will not change. If you have some of your own header files in the pre-compiled header, then every change in your header requires to recompile the pre-compiled header which in turn will require a recompile of everything.

JoeCFD

@nicker-player
https://doc.qt.io/qt-5/qmake-advanced-usage.html
{{{
qnx: target.path = /tmp/$${TARGET}/bin <=== the path of your app for installation on QNX(blackbeery OS)
else: unix:!android: target.path = /opt/$${TARGET}/bin <=== the path of your app for installation of non android build on Linux
!isEmpty(target.path): INSTALLS += target <=== add your target for installation
}}}

nicker player

@JoeCFD
Ive modified the pro file by the way you've mentioned in the topic.It helps,thanks a lot.
And I have to put the 'install' into the mingw32-make arguments.
But when I moved the old dlls in the target.files,the qmake occurs the errors that could not open the dlls which have been removed from the project.
I dont know why,dose it has to recompile the whole project once changed or removed the dlls or rescources?
But when i recompiled the project,the error of the 'could not open the dlls ' which have been removed dosent disappear.

Asperamanca

Use forward declarations in headers where possible.
This is possible if you only use references or pointers to objects in the header.

So, instead of

#include <QObject>
#include <SomeValueClass>
#include <Something>

class Example
{
public:
   SomeValueClass m_Value;
   const Something& m_Something;
   QObject* m_pRootObject = {};
}

you can do

#include <SomeValueClass>
class QObject;
class Something;

class Example
{
public:
   SomeValueClass m_Value;
   const Something& m_Something;
   QObject* m_pRootObject = {};
}

You can even be more aggressive:

#include <memory>
class SomeValueClass;
class QObject;
class Something;

class Example
{
public:
   std::unique_ptr<SomeValueClass> m_pValue;
   const Something& m_Something;
   QObject* m_pRootObject = {};
}

In general, if you have crisscrossing includes in header files, there's a high likelihood that any change to a header file will trigger a cascade of recompilations. Using forward declarations can break those dependencies and reduce compilation time...by a lot.