Taking the GNU make application as an example, when I create a makefile it is likened to a Visual Studio project file in that it contains the list of files and other items needed to compile an application. The makefile contains the path to the compiler as well as the path to all the files that could possibly be used in the compiling operation. The MAKE application reads the makefile and combines the sources into 1 file which the compiler then reads and converts into the relevant assembly/machine code.
The #include directive is a directive that tells the make file to:
“include the contents of this file into this point of the larger file that you’re making to feed to the compiler then resume with the current file”.
The MAKE application also tells the compiler where to “emit” the result of the compile operation once the compiling is completed. In this regard a Visual Studio .csproj file is technically a XML based makefile for a Microsoft specific MAKE application.
Is this understanding of makefiles correct?
Approximately, yes. However there are numerous details to cavil at.
That is reasonably close to accurate.
The makefile typically does not contain the path to the compiler, though it could. It would contain a list of the files that might be used in the compilation.
This is not very accurate. The details vary, but the aggregation is not done by MAKE, but by the compilers that MAKE invokes. MAKE can be used for other tasks than simple source to machine code translation.
GNU Make (and POSIX Make) supports an
includedirective to incorporate other fragments of a makefile. The C and C++ compilers recognize the#includedirective – and the makefile often needs to be briefed on which headers (included by the#includedirective) are needed to compile the program. However,#includeis a simple comment in a makefile.The makefile contains the information about where the generated code should be placed, and the compiler is told if it needs to know.
That is a reasonable approximation to the description.