How to saving the compling time ?
-
Ive tried a lot of methods to accelerating the compling process.
such as
1.using the preheader for the libraries
2.using the compile option with "-j n" for the multi core of cpu
3.used the codes by linked libraries
4.not include the classes head file if needed,other wise included in the source files.
5.using the multi pro setbut it seemed dosent work.The time for compiling seemed not changed.
It will take a long time only if modified one file,and it seemd to recompile the whole project only if modified one file.
So anyone could tell me how to sovle the problem?And the compiler platform is qt5.12 & mingw32-make.
By the way,how to using a common variety for the sub .pro files?Like the extern usage of the cplus code. -
Ive tried a lot of methods to accelerating the compling process.
such as
1.using the preheader for the libraries
2.using the compile option with "-j n" for the multi core of cpu
3.used the codes by linked libraries
4.not include the classes head file if needed,other wise included in the source files.
5.using the multi pro setbut it seemed dosent work.The time for compiling seemed not changed.
It will take a long time only if modified one file,and it seemd to recompile the whole project only if modified one file.
So anyone could tell me how to sovle the problem?And the compiler platform is qt5.12 & mingw32-make.
By the way,how to using a common variety for the sub .pro files?Like the extern usage of the cplus code.@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.
-
ps:
os:windows 7
and qmake
and i used the harddisk of SSDand 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? -
With cmake you can save many time because cache many objects. But it is more complexes of qmake :-(
@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.txtThe 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 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.txtThe 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.@Christian-Ehrlicher , ok sorry.
-
ps:
os:windows 7
and qmake
and i used the harddisk of SSDand 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?@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
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.@JoeCFD
Thanks very mush.It helps.
Andqnx: 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?
-
Ive tried a lot of methods to accelerating the compling process.
such as
1.using the preheader for the libraries
2.using the compile option with "-j n" for the multi core of cpu
3.used the codes by linked libraries
4.not include the classes head file if needed,other wise included in the source files.
5.using the multi pro setbut it seemed dosent work.The time for compiling seemed not changed.
It will take a long time only if modified one file,and it seemd to recompile the whole project only if modified one file.
So anyone could tell me how to sovle the problem?And the compiler platform is qt5.12 & mingw32-make.
By the way,how to using a common variety for the sub .pro files?Like the extern usage of the cplus code.@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
Thanks very mush.It helps.
Andqnx: 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?
@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
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
}}}@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. -
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.