3 ms·

> Even on my MacBook, I don't remember installing it explicitly. It's there, but last I checked, it only supports building with the Apple-supplied toolchains (

> Even on my MacBook, I don't remember installing it explicitly. It's there, but last I checked, it only supports building with the Apple-supplied toolchains (Xcode). If you want to use anything else, do yourself a favor and install gmake(1) from MacPorts. For C/C++ projects that are simple enough, I can reuse the same Makefile with only minor changes, and it works on both Linux and macOS, with support for sanitizers and valgrind(1). CLion eats it up like it were candy, although the gathering of sources is automated with find(1), and even respects my `--sysroot` setting. CMake has good cross-platform capabilities, but GNU make gives me more control over the actual compiler and linker invocations, and its CLI is less horrible than that of CMake.

saurik 2y ago
The version of make which ships with Xcode is old (as Apple has stopped updating GPL software in general, and hopefully new builds of GNU make are GPL3 anyway), but it is otherwise not in any way somehow tied to Xcode's toolchain: it is a normal copy of GNU make 3.81 which runs commands the same as any other copy of make (as you provide them, and using the path).
- tempodox 2y ago
  Yep, could have been just bugs that I misinterpreted. Anyway, the stuff I want to do works with current gmake, but not with `/usr/bin/make` on macOS.
Wololooo 2y ago
I know this is not your main point, and you touched briefly on it but, cmake is absolutely terrible. It is supposed to make the building process more straight forward and painless but what it brings to the table is * Weird bugs: In one version of cmake would return the python version that I had to be 0.16 (????) and the only fix was to update the cmake version * Messy Structure: Under the guise of giving freedom to the person designing their build with no real enforcement of any rules, in any way, people can write their own absolute craptastic version of cmake scripts which really really is going to make you lose your mind (mind you some people leverage it but it is the exception not the rule) * Opaque process: Due to the fact that the structure can be messy you are never really quite sure of what it is doing and which compile flags are effectively fed to the compiler as well as sometimes totally ignoring the library you explicitly ask it to use and trying to find another one... OK maybe this is a bit superlative, but unfortunately for me, reflects well my experience with using cmake and feels like an extra item between me and getting things working painlessly... But I might have been doing it wrong.
- iamthemalto 2y ago
  I understand this perspective if considering CMake in the past (i.e. pre 3.0 or so), but in my experience CMake today is much nicer (albeit definitely still not without its flaws). Specially for the points you mention: * “Weird bugs”: I suspect CMake wasn’t finding the version of Python you wanted because your find_package command was just finding a different version first. This is much easier to debug today by using —-debug-find-pkg=Python, which will print all the places it searches Python for and what it finds. You can then modify your find_package invocation as appropriate to find the Python you really want to use. * Messy structure: yes, unfortunately I’ve also seen my fair share of nightmare-inducing CMake files. * Opaque process: here I actually quite disagree. In my experience I’ve found it super easy to modify things like compiler flags (just use target_compile_options, or add_compile_options for directory wide options). And what made a big difference was using Ninja as the generator (I also use Ninja on Windows), which makes it super easy to view the final compiler commands that will actually be invoked. CMake is essentially a compiler that emits Ninja on the backend, and several times it’s been invaluable to confirm in the generated Ninja code what is actually being invoked. CMake is definitely not perfect, but it’s much better than what it used to be! It’s ultimately a perfect match for C++ (both extremely powerful, configurable, hamstrung with decades of backwards compatibility, terrible ergonomics, etc.).

saurik 2y ago

The version of make which ships with Xcode is old (as Apple has stopped updating GPL software in general, and hopefully new builds of GNU make are GPL3 anyway), but it is otherwise not in any way somehow tied to Xcode's toolchain: it is a normal copy of GNU make 3.81 which runs commands the same as any other copy of make (as you provide them, and using the path).

tempodox 2y ago
Yep, could have been just bugs that I misinterpreted. Anyway, the stuff I want to do works with current gmake, but not with `/usr/bin/make` on macOS.

Wololooo 2y ago

I know this is not your main point, and you touched briefly on it but, cmake is absolutely terrible. It is supposed to make the building process more straight forward and painless but what it brings to the table is * Weird bugs: In one version of cmake would return the python version that I had to be 0.16 (????) and the only fix was to update the cmake version * Messy Structure: Under the guise of giving freedom to the person designing their build with no real enforcement of any rules, in any way, people can write their own absolute craptastic version of cmake scripts which really really is going to make you lose your mind (mind you some people leverage it but it is the exception not the rule) * Opaque process: Due to the fact that the structure can be messy you are never really quite sure of what it is doing and which compile flags are effectively fed to the compiler as well as sometimes totally ignoring the library you explicitly ask it to use and trying to find another one... OK maybe this is a bit superlative, but unfortunately for me, reflects well my experience with using cmake and feels like an extra item between me and getting things working painlessly... But I might have been doing it wrong.

iamthemalto 2y ago
I understand this perspective if considering CMake in the past (i.e. pre 3.0 or so), but in my experience CMake today is much nicer (albeit definitely still not without its flaws). Specially for the points you mention: * “Weird bugs”: I suspect CMake wasn’t finding the version of Python you wanted because your find_package command was just finding a different version first. This is much easier to debug today by using —-debug-find-pkg=Python, which will print all the places it searches Python for and what it finds. You can then modify your find_package invocation as appropriate to find the Python you really want to use. * Messy structure: yes, unfortunately I’ve also seen my fair share of nightmare-inducing CMake files. * Opaque process: here I actually quite disagree. In my experience I’ve found it super easy to modify things like compiler flags (just use target_compile_options, or add_compile_options for directory wide options). And what made a big difference was using Ninja as the generator (I also use Ninja on Windows), which makes it super easy to view the final compiler commands that will actually be invoked. CMake is essentially a compiler that emits Ninja on the backend, and several times it’s been invaluable to confirm in the generated Ninja code what is actually being invoked. CMake is definitely not perfect, but it’s much better than what it used to be! It’s ultimately a perfect match for C++ (both extremely powerful, configurable, hamstrung with decades of backwards compatibility, terrible ergonomics, etc.).