2 ms·

> For example, try to tell CMake how to create a freestanding executable (one that doesn’t link to the system C library). You end up fighting against the abstra

> For example, try to tell CMake how to create a freestanding executable (one that doesn’t link to the system C library). You end up fighting against the abstractions inherent in its design. What's wrong with target_link_options(foo PRIVATE -static-libgcc -static-libstdc++) I don't understand how that particular powrshell block is more flexible than cmake from what I can see it does less (it's windows specific - mine works on Linux, Mac, windows, and also works with cross compilation toolchains out of the box). If I want to add specific warnings I can use target_compile_options to get exactly the same behaviour. > won’t suddenly break if you install a second set of compilers for another project, I'm genuinely curious - have you used cmake? Cmake has sensible defaults but is completely customizable. Cmake uses platform standards - if you overwrite the CC variable it will use that toolchain instead. Cmake has its warts, for sure, but lack of flexibility is definitely not one of them.

dundarious 4y ago
I have extensively used CMake since years before it supported the target_ options, and years afterwards. So I was using it before, during, and after the breath of fresh air that was the shift to what is now called “modern CMake”, i.e., bjam/b2 style (define targets with private/public/interface dependencies/options). As you can guess, I’ve also used bjam/b2 extensively. I’ve also used meson to a more limited extent. And when I say “used”, I mean where I’ve written many build files from scratch myself, in a professional capacity. I’m always the “build system expert” on my team because of how much experience I have. If working on a team where people know the compilers, and where build times are kept reasonable (so not using lots of templates in C++), then on a practical level I recommend not using a build system at all, and just writing a super simple shell script (unity builds are easier there too). I still recommend CMake sometimes though — especially if the main requirement is just “gimme some machine code, who cares how, and who cares about using ASAN, etc.”, and the second most important requirement is to ship the code to the open source community. BTW, I mean freestanding as in “does not link to any C library”, rather than “statically links to the C library”. declare -a free=(-std=gnu99 -DEXAMPLE_FREESTANDING -nostartfiles -nostdlib -nodefaultlibs -ffreestanding -fno-stack-protector)
- maccard 4y ago
  > then on a practical level I recommend not using a build system at all, and just writing a super simple shell script (unity builds are easier there too). But the minute you introduce someone who is familiar with windows or prefers an IDE workflow this falls apart. You are also limited to the platforms, compilers and IDEs that you write the script to support. That's not flexible, that's inflexible. Also, cmake has supported unity builds out of the box for a few years now [0] and before that cotire existed. > I mean freestanding as in “does not link to any C library”, rather than “statically links to the C library”. Ok, great so just use target_compile_optiond in the exact same way as you've just listed the arguments? I don't see how cmake stops you from doing that by architectural decisions at all.
  - dundarious 4y ago
    Writing a new “call the compiler like so” line is pretty easy — pretty flexible, I’d say. Let’s say a new compiler came along tomorrow, where all the options have plus signs instead of minus signs (“+O +DPREPROCESSOR_DEFINITION”), I’d have an easier time adding a single line to a script than I would writing a toolchain file for CMake, or more likely, having to look at the CMake source code. That is a not unreasonable, but still quite pathological example. But it’s a window into the annoying world of manipulating compiler commands via the indirect mechanism of CMake. If you have very precise requirements, especially regarding order of arguments on the command line (a common issue with cl but to a lesser extent other compilers also), then using CMake can be like performing surgery with chopsticks. If you have simpler needs, it can be like eating sticky food with chopsticks — i.e., a convenient way to keep your hands clean. It seems like I just disagree with how steep the slippery slope is between those two points. As for editors and whatnot, I’ve worked on teams where people used Visual Studio, vim, CLion, VS Code, via these scripts. Most with full IDE integration, some without (some people don’t use it). The easiest pathway is to generate compile_commands.json — ironically, this is already something extremely close to the script, so it’s trivial to automatically generate from the script. I was just saying as a postscript that I meant something different by freestanding. I agree that it’s totally orthogonal to your argument and mine.
    - 4y ago

dundarious 4y ago

I have extensively used CMake since years before it supported the target_ options, and years afterwards. So I was using it before, during, and after the breath of fresh air that was the shift to what is now called “modern CMake”, i.e., bjam/b2 style (define targets with private/public/interface dependencies/options). As you can guess, I’ve also used bjam/b2 extensively. I’ve also used meson to a more limited extent. And when I say “used”, I mean where I’ve written many build files from scratch myself, in a professional capacity. I’m always the “build system expert” on my team because of how much experience I have. If working on a team where people know the compilers, and where build times are kept reasonable (so not using lots of templates in C++), then on a practical level I recommend not using a build system at all, and just writing a super simple shell script (unity builds are easier there too). I still recommend CMake sometimes though — especially if the main requirement is just “gimme some machine code, who cares how, and who cares about using ASAN, etc.”, and the second most important requirement is to ship the code to the open source community. BTW, I mean freestanding as in “does not link to any C library”, rather than “statically links to the C library”. declare -a free=(-std=gnu99 -DEXAMPLE_FREESTANDING -nostartfiles -nostdlib -nodefaultlibs -ffreestanding -fno-stack-protector)

maccard 4y ago
> then on a practical level I recommend not using a build system at all, and just writing a super simple shell script (unity builds are easier there too). But the minute you introduce someone who is familiar with windows or prefers an IDE workflow this falls apart. You are also limited to the platforms, compilers and IDEs that you write the script to support. That's not flexible, that's inflexible. Also, cmake has supported unity builds out of the box for a few years now [0] and before that cotire existed. > I mean freestanding as in “does not link to any C library”, rather than “statically links to the C library”. Ok, great so just use target_compile_optiond in the exact same way as you've just listed the arguments? I don't see how cmake stops you from doing that by architectural decisions at all.
- dundarious 4y ago
  Writing a new “call the compiler like so” line is pretty easy — pretty flexible, I’d say. Let’s say a new compiler came along tomorrow, where all the options have plus signs instead of minus signs (“+O +DPREPROCESSOR_DEFINITION”), I’d have an easier time adding a single line to a script than I would writing a toolchain file for CMake, or more likely, having to look at the CMake source code. That is a not unreasonable, but still quite pathological example. But it’s a window into the annoying world of manipulating compiler commands via the indirect mechanism of CMake. If you have very precise requirements, especially regarding order of arguments on the command line (a common issue with cl but to a lesser extent other compilers also), then using CMake can be like performing surgery with chopsticks. If you have simpler needs, it can be like eating sticky food with chopsticks — i.e., a convenient way to keep your hands clean. It seems like I just disagree with how steep the slippery slope is between those two points. As for editors and whatnot, I’ve worked on teams where people used Visual Studio, vim, CLion, VS Code, via these scripts. Most with full IDE integration, some without (some people don’t use it). The easiest pathway is to generate compile_commands.json — ironically, this is already something extremely close to the script, so it’s trivial to automatically generate from the script. I was just saying as a postscript that I meant something different by freestanding. I agree that it’s totally orthogonal to your argument and mine.
  - 4y ago