Compiling Multi-file C++ Source Code with CMake 

You're welcome. Glad it's helpful.

Glad the video helped.

No plans for autotools, because I find it to be an absolute nightmare to use. Some people love to hate CMake, but it's a huge step up from autotools.

> But I got you haha Nah, you're just nitpicking. :-P Yes, it created a VS solution. I'm using "make file" as a generic catch-all for the file(s) that are then used for the actual build. The video isn't intended only for Windows devs.

Only if you want to follow the tutorial 100%, and do a complete build from scratch using the commands I give. Otherwise, if the build scripts have already been created in the build folder (by "cmake .."), then you only need to run "cmake --build ." from within the build folder to run the actual build.

@@KeaSigmaDelta thank you so much, I subed please don't mind my poor English, since It's not my native tongue

@@punchline1729 You're welcome.

I recommend keeping it the way it is in the video. The ${PROJECT_NAME} variable contains the project's name, so the executable will be given the same name as the project. If you ever want to change the project name, then you only have to change it once (in the project() call) instead of twice. In programming you generally want to avoid repeating yourself... Using a ${SOURCE_FILES} variable is far more flexible than adding files directly to add_executable(). For example, you may have source files that are specific for Windows, MacOS, etc. It's easy to conditionally add them to the ${SOURCE_FILES} variable, whereas you'd have to have multiple add_executable() calls otherwise, with the common files repeated.

@@KeaSigmaDelta Thank you for the clarification👍🤝

You're welcome.

You're welcome.

Glad it helped.

Part of it's probably habit, which started with older build systems. I do think the script looks cleaner when setting a variable for source-files, though. Plus it's easier to switch when you do get to the point that it becomes necessary.

I have gcc compiler installed

You can skip that step if you only have one compiler installed. CMake will automatically use the compiler you installed. I have multiple compilers installed, and therefore need to tell it which one to use. To change the chosen compiler, you need to click the tool icon on the CMake status bar (the blue bar at the bottom of the video). In the video you can see [Visual Studio Community 2019 Release -amd64] to the right of the tool icon. Unfortunately, they changed the CMake Tools plugin since I created the video, and it now hides the status bar by default (and it's no longer blue). You can enable the status bar in the plugin's settings. However, there's no need to do this if you have only one compiler installed.

My personal opinion: no. It's best to be 100% precise as to which files are included in the build. That means you add them all into the build script. If the list of files is starting to get too large, then it's probably time to organize your files into sub-directories for different parts of the code (e.g., graphics code and audio code in separate sub-directories). Then you add the files in separate CMakeLists.txt files which you include into the main one. This is one of the things I plan to cover in The CMake Tutorial: cmaketutorial.com/

@@KeaSigmaDelta thanks. makes sense.

Not really. The compiler must do exactly what it's told, which means giving it precise instructions. I suppose you could write a compiler that tries to guess (e.g., just compile all the *.c/*.cpp files in a directory), but that's guaranteed to get things wrong. So, you'd be back to giving it more precise instructions again. A few quick examples where compiling everything would be a problem: - Some source files are for specific platforms (e.g., different files for Windows, Linux, MacOS X, etc.) - Some source files need to be compiled with special flags (e.g., some files should be compiled with SIMD enabled, and others without) On top of that, you may be using external libraries, and you may need specific versions of those.