Rethink flags presets

[sharadhr]

Rethink flags presets

[friendlyanon]

I guess renaming them is a fair suggestion, the names were given with each platform's "default" configuration (Windows - MSVC, Linux - GCC/Clang, Mac - AppleClang) in mind, but putting those in the name instead would more clearly describe their intended usage to someone trying to use e.g. MinGW on Windows. As an FYI, some of the hardening flags are not applicable for AppleClang, that's why the *nix preset was split.

it does feel weird to require this sort of env-variable mangling

You shouldn't do that. You can provide CMake with the flags using a toolchain file. Tooling will still understand the build perfectly fine if you instead load a toolchain file in the preset. Toolchain files are just CMake scripts, where you can put some sort of logic to better select flags that are currently in the presets, but I would heavily recommend keeping that logic very light. Remember that the whole point of the presets is to externalize things that aren't pertinent to build and usage requirements.

[friendlyanon]

I am aware that the flags presets are repetitive and that they don't cover every possible setup, which is mentioned in the non-goals of this project: https://github.com/friendlyanon/cmake-init#non-goals
The idea behind the flags is that they are mainly for CI that also happens to work on "default" configurations with good enough experience. $env{} will definitely not be abused.

User presets can and are meant to also be freely used to override parts of the main presets. With that in mind, I'm not sure what to change in that regard. Regarding MinGW, that was looked at in #89 and I don't see what needs to be done here. MinGW is definitely not the norm for Windows, so I would rather not have it in cmake-init by default.

Fortify not working with ASAN was no something I was aware of though. From what I read, it's best to just remove the -D one in this case.

[sharadhr]

that they don't cover every possible setup, which is mentioned in the non-goals of this project: https://github.com/friendlyanon/cmake-init#non-goals

That's fair, and I don't think it's reasonable to expect cmake-init to support every possible combination of compiler and platform there is. However, I think renaming what is already present would make things clearer—the real difference between the flags-linux + flags-darwin and flags-windows sets are the syntax of the driver flags, rather than the OS they're running on.

$env{} will definitely not be abused

Bummer. This is a CMake limitation, honestly, and it does feel weird to require this sort of env-variable mangling...

MinGW

Simply put, flags-windows can't be used to compile with MinGW, simply because the tools provided by MinGW don't accept cl-style flags (it is called Minimalist GNU for Windows). Ergo I said flags-linux is not particularly well-named: it doesn't really contain anything strictly Linux-specific, is in the GNU style of compiler arguments, and it could be set up by end-users to compile for any platform that uses GCC, Clang, ICX, NVCC, or any number of compilers that have a shared GNU-like heritage.

Ergo this whole renaming exercise.