>>106158581
are you doing something more complex than just consuming a couple translation units all with the same config or using a single version of a library with a single ABI always located in the same place regardless of system?
then that's when you start thinking about things like cmake or makefiles
cmake is a meta build system for portably creating platform specific build tool files like makefiles
though these days that basically just boils down to creating the build files for ninja (which is basically a high speed super minimal portable make not meant for human usage) unless you specifically need msbuild files in case of some weird visual studio thing
instead of shoving everything into one compiler invocation and then expecting the compiler to properly handle dispatching everything, build tools automate scheduling and invoking the different steps of compilation while also handling things like avoiding rebuilding unchanged files or parallel task invocation
cmake is terrible but it handles things like compiler feature checking, dependency resolution, platform config, launching some build utilities, compiler compat, handling multiple build configurations for release/debug/etc., installation, compiling for a different architecture than your current one, and other shit in the most widely supported manner
even if you don't want to use it fucktons of other projects do which means in order to consume a lot of libraries you have to use cmake's dependency resolution which handles cmake install configs and paths
and the only real way to learn it is to read and write a lot of cmakefiles
no one writes good cmake code, but try to use properties and generators as opposed to just setting variables to values
you should be using an IDE/editor with C++ support that implicitly handles managing clangd and generating and feeding it compile_commands.json like qtcreator, you shouldn't even need to touch the language server directly at all unless you're doing something fucky
