(continued)

If interested in a more detailed explanation, yo may want to check out Structured Computer Organization by Tannebaum if you can find it. He defines a "hiearchy" at which the lowest level (level 0) compromises digital logic (i.e, gates and switches), the next level (1) descripts the microprogramming level, also sometimes called the "register-transfer level" (RTL), level 2 would be the machine language level (CPU instructions, i.e, MOV, ADD, SUB, etc.) , level 3 the OS, level 4 assembly language level and finally level 5 the high level languages. At each stage generally you have some time of translation from one language type to the next, though the the OS (level 3) is a bit of exception because in most circumstances it doesn't translate the instructions from level 4 (assembly), although because it does manage so many important things like memory, file systems and devices, it is enough to really justify its own level.

It is high level, its just unmanaged and unsafe,. with a very thin standard library. (Lacking containers, for instance).

Other languages generally don't use C as an abstraction layer - i.e, they don't "compile" to C. Alhough some, such as Python, have interpreters written in C (CPython), Python code itself compiles to its own bytecode that doesn't have any direct relation to C.

This is why C, as well the few other systems level languages (such as Rust) are not viewed as comprising a "level" ke assembly.

For a kinder/gentler introduction,m you can try GitHub desktop.

One of the downsides (or upsides depending your perspective) it will automatically stage everything, so watch out of that. you're tot including temporaries like results of build.

Ok here's one I don't quite get .. after I run cmake from build dir, it works fine with no erros. But that apparently after that, you run make, and the cmake 'abstraction' is still there because I am getting cmake errors when running make, which makes no sense.

@sbiewald 1. Are you referring to --log-level? I'll have to try that. Though really, it should probably be the default.

2. Ok I can see its much better to create a 'build' dir and run cmake from there. A warning would have been nice. Or maybe cmake should do that by default.

3. I'm on MacOS and Linux so no VS here. On that point, would be nice if there was a standard way of doing things, at least in VS if the compiler couldn't find an incude file I would know where to fix that and could do it in 10 seconds intead of the several hours I have spent fighting CMake, but it seems like everyone does everything different. VS also has the nice feature of actually telling you what command are being invoked, by default.