Speed up compiling about thrive HOT 6 CLOSED

I don't really have much experience with compiling large C++ projects, but i know that it is notorious for long compile times!
I don't have enough understanding of the build system to suggest anything concrete, but i wouldn't get my hopes too high.

from thrive.

That's what I feared. What bothers me is that only one object file is being compiled (or at least should be). I thought that the linking phase would be much faster since there would be no need for as much optimization, but I am only speculating here, as I can see reasons for linking to be just as complicated. I'm going to make a minor change to the code, install, and see where the bottleneck is.

(Wishful thinking below. Ignore if you want)

Ugh. I wish we could code in Java. It would make everything so much easier. It can be as fast or faster than C++ thanks to just-in-time compiling. Unfortunately, garbage collection can be the source of unacceptable lag spikes, and for that reason, we have to deal with the woes of C++ compiling. If only there were a free language to code in that modified itself quickly like Java but had C++-like memory allocation and deallocation.

from thrive.

The following two commands seemed to take the longest time. It seems like linking all the libraries together at the end takes a while, but I don't fully understand yet. Is our program statically or dynamically linked to its libraries? If it's dynamically linked, then why is there a library linking phase like this in compile time. I'm probably just misinterpreting these commands. I'll look more into it.

Also: what, exactly, is RunTests.exe?

Commands below:

C:\MinGW\bin\g++.exe -std=gnu++0x -g -Wl,--whole-archive CMakeFiles\RunTests.dir/objects.a -Wl,--no-whole-archive -o RunTests.exe -Wl,--out-implib,libRunTests.dll.a -Wl,--major-image-version,0,--minor-image-version,0 libThrive.a contrib\googletest\libgtest_main.a C:\MinGW\install\lib\libboost_chrono-mt.dll C:\MinGW\install\lib\libboost_date_time-mt.dll C:\MinGW\install\lib\libboost_filesystem-mt.dll C:\MinGW\install\lib\libboost_thread-mt.dll C:\MinGW\install\lib\libboost_system-mt.dll C:\MinGW\OgreSDK\lib\debug\libOgreMain_d.dll.a C:\MinGW\OgreSDK\lib\debug\libOIS_d.dll.a C:\MinGW\install\lib\libBulletDynamics.a C:\MinGW\install\lib\libBulletCollision.a C:\MinGW\install\lib\libLinearMath.a C:\MinGW\install\lib\libBulletSoftBody.a contrib\luabind\src\libluabind.a contrib\lua\liblua.dll.a -lm contrib\googletest\libgtest.a -lpthread -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

C:\MinGW\bin\g++.exe -std=gnu++0x -g -Wl,--whole-archive CMakeFiles\Thrive.dir/objects.a -Wl,--no-whole-archive -o Thrive.exe -Wl,--out-implib,libThrive.dll.a -Wl,--major-image-version,0,--minor-image-version,0 libThrive.a C:\MinGW\install\lib\libboost_chrono-mt.dll C:\MinGW\install\lib\libboost_date_time-mt.dll C:\MinGW\install\lib\libboost_filesystem-mt.dll C:\MinGW\install\lib\libboost_thread-mt.dll C:\MinGW\install\lib\libboost_system-mt.dll C:\MinGW\OgreSDK\lib\debug\libOgreMain_d.dll.a C:\MinGW\OgreSDK\lib\debug\libOIS_d.dll.a -lpthread C:\MinGW\install\lib\libBulletDynamics.a C:\MinGW\install\lib\libBulletCollision.a C:\MinGW\install\lib\libLinearMath.a C:\MinGW\install\lib\libBulletSoftBody.a contrib\luabind\src\libluabind.a contrib\lua\liblua.dll.a -lm -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

from thrive.

Unfortunately, there's no easy fix for that. It's mostly an issue with MinGW for Windows, which is notoriously slow, especially with linking. The test you mentioned (recompiling only game.cpp) takes me 25 seconds for native Linux compiling, Cross compiling from Linux to Windows with MinGW takes 18 seconds (no idea why it's faster).

RunTests.exe runs a suite of unit tests for stuff that is easy to test. We could add an EXCLUDE_FROM_ALL to the cmake command for generating the RunTests executable so that it's not produced by default.

from thrive.

I doubted that there would be an easy fix. The weird part is that the longest part of the linking phase, at least for me, is when the program links the ".a" libraries together. Why does that phase even exist at all if the executable ends up depending on several dlls anyway? What is being linked?

from thrive.

I'm closing this as it isn't an actual issue but rather something that will always be useful to achieve.

from thrive.