building minetest from source code question
building minetest from source code question
Lets say you build minetest from source code into minetest folder. Then you make a small change to camera.cpp do you need to build whole minetest again or can you build just that camera.cpp file and put that camera.cpp into minetest folder?
Re: building minetest from source code question
When you make changes to a .cpp file you have to recompile.
- Beerholder
- Member
- Posts: 199
- Joined: Wed Aug 03, 2016 20:23
- GitHub: evrooije
- In-game: Beerholder
Re: building minetest from source code question
You do not have to completely recompile all the minetest object files when you only change one .cpp file, unless you do an initial make, a make clean or potentially when changing some of the CMake parameters that regenerate the Makefiles.
You do have to relink the minetest executable, but this is peanuts compared to a full compilation stage and usually takes a couple of seconds at most.
What happens is that minetest (the executable) depends on camera.o (and a whole bunch of other .o files). camera.o depends on camera.cpp (and camera.cpp depends on camera.h and some other header files, more on that later).
You change camera.cpp -> camera.cpp is recompiled to a new camera.o and during the link stage, the new camera.o is linked with the other (unmodified/ old) object files that were already there into a new minetest executable.
If you need to change header files, this is a different story. Suppose you had changed camera.h, this header file is actually used in a lot of other .cpp files, and not just camera.cpp, as there is other code that needs to use the camera system for one reason or another. Since a header file specifies the entry points/ symbols that other .o files may need to refer to, those other .o files also need to be recompiled. Additionally, header files can include other header files as well, making for a very murky dependency graph causing .cpp files that seem to be unrelated to the .h file you modified to be compiled anyways.
So in summary, after a first (full) Minetest build:
Change a .cpp file and only that .cpp files is recompiled into a .o file, after which the new .o file and the other .o files that were already there are then relinked into a new executable.
Change a .h file used by a lot of .cpp files, the header and all those .cpp files need to be recompiled to their respective .o files after which all the .o files (new and untouched) have to again be relinked.
Change a .h file that is included in a lot of other header files and .cpp files, and you quickly get into a situation where most if not all of the code needs to be recompiled.
Also, the word "build" implies multiple steps in this process (dependency checking, preprocessing, compilation, linking). And finally, the above is written from a Linux perspective, but for Windows it works pretty much the same.
You do have to relink the minetest executable, but this is peanuts compared to a full compilation stage and usually takes a couple of seconds at most.
What happens is that minetest (the executable) depends on camera.o (and a whole bunch of other .o files). camera.o depends on camera.cpp (and camera.cpp depends on camera.h and some other header files, more on that later).
You change camera.cpp -> camera.cpp is recompiled to a new camera.o and during the link stage, the new camera.o is linked with the other (unmodified/ old) object files that were already there into a new minetest executable.
If you need to change header files, this is a different story. Suppose you had changed camera.h, this header file is actually used in a lot of other .cpp files, and not just camera.cpp, as there is other code that needs to use the camera system for one reason or another. Since a header file specifies the entry points/ symbols that other .o files may need to refer to, those other .o files also need to be recompiled. Additionally, header files can include other header files as well, making for a very murky dependency graph causing .cpp files that seem to be unrelated to the .h file you modified to be compiled anyways.
So in summary, after a first (full) Minetest build:
Change a .cpp file and only that .cpp files is recompiled into a .o file, after which the new .o file and the other .o files that were already there are then relinked into a new executable.
Change a .h file used by a lot of .cpp files, the header and all those .cpp files need to be recompiled to their respective .o files after which all the .o files (new and untouched) have to again be relinked.
Change a .h file that is included in a lot of other header files and .cpp files, and you quickly get into a situation where most if not all of the code needs to be recompiled.
Also, the word "build" implies multiple steps in this process (dependency checking, preprocessing, compilation, linking). And finally, the above is written from a Linux perspective, but for Windows it works pretty much the same.
Who is online
Users browsing this forum: No registered users and 25 guests