# \_MBCS in 4.2, and policy CMP0204

**URL:** https://discourse.cmake.org/t/mbcs-in-4-2-and-policy-cmp0204/15738
**Category:** Code
**Tags:** os:windows
**Created:** [July 5, 2026, 3:29pm UTC](https://discourse.cmake.org/t/mbcs-in-4-2-and-policy-cmp0204/15738 "2026-07-05T15:29:04Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![johan556](https://discourse.cmake.org/user_avatar/discourse.cmake.org/johan556/32/788_2.png) [@johan556](https://discourse.cmake.org/u/johan556)
#### Post date: [July 5, 2026, 3:29pm UTC](https://discourse.cmake.org/t/mbcs-in-4-2-and-policy-cmp0204/15738/1 "2026-07-05T15:29:04Z")

</div>

I recently updated one of my projects to use cmake\_minimum\_required(VERSION 4.2).

My project sets the defines UNICODE and \_UNICODE globally, so I assumed that the new policy CMP0204 should work without problem for me. [It says:](https://cmake.org/cmake/help/latest/policy/CMP0204.html)

> CMake 4.2 and above, when targeting the MSVC ABI, prefer to compile sources with \_MBCS defined by all generators unless another charset preprocessor definition is found (\_UNICODE or \_SBCS).

But it seems like \_UNICODE is not “found” in my project, even though it is set. After some experimentation I have concluded that:

- if \_UNICODE is set via add\_compile\_definitions() it is found
- if \_UNICODE is set via target\_compile\_definitions() it is found
- if \_UNICODE is set via CMAKE\_CXX\_FLAGS\_DEBUG and CMAKE\_CXX\_FLAGS\_RELEASE, or CMAKE\_CXX\_FLAGS, then it is NOT found

I know that using variables like CMAKE\_CXX\_FLAGS\_DEBUG for “permanent” settings is not good style. But my current project happened to use it.

The effect on the project was to get all of \_MBCS, \_UNICODE, and UNICODE set when building with Visual C++, and the same with Ninja.

Is this difference in behavior, depending on which method is used, intentional?

I’m thinking about switching to setting \_UNICODE and UNICODE via add\_compile\_definitions(), to get past this problem. I guess that way would be equally “global” for my project, and will work right away with 4.2 behaviour.

---

<div class="post-metadata">

### Author: ![vito.gamberini](https://discourse.cmake.org/user_avatar/discourse.cmake.org/vito.gamberini/32/4376_2.png) [@vito.gamberini](https://discourse.cmake.org/u/vito.gamberini)
#### Post date: [July 6, 2026, 7:43am UTC](https://discourse.cmake.org/t/mbcs-in-4-2-and-policy-cmp0204/15738/2 "2026-07-06T07:43:46Z")

</div>

CMake only checks a target’s evaluated compile definitions for the preprocessor defines, not the complete flag line. Generally CMake tries to avoid parsing arbitrary flag fragments like `CMAKE_<LANG>_FLAGS` for infomation, only relying on flag entries in dedicated properties. That means it only sees definitions supplied via the various `COMPILE_DEFINITIONS` properties.

This is maybe a bug, you can open one describing your use case on the tracker. I think it’s a little strange CMake has no abstraction for describing compile definitions from cache variables other than `CMAKE_<LANG>_FLAGS`, but then ignores the `*_FLAGS` variables of this policy.

CMake either needs a dedicated cache variable for compile definitions, or needs to consider the language-specific flags in its calculation for MSVC encoding.

---

<div class="post-metadata">

### Author: ![johan556](https://discourse.cmake.org/user_avatar/discourse.cmake.org/johan556/32/788_2.png) [@johan556](https://discourse.cmake.org/u/johan556)
#### Post date: [July 22, 2026, 6:29pm UTC](https://discourse.cmake.org/t/mbcs-in-4-2-and-policy-cmp0204/15738/3 "2026-07-22T18:29:47Z")

</div>

> [@vito.gamberini](#):
>
> Generally CMake tries to avoid parsing arbitrary flag fragments like `CMAKE_<LANG>_FLAGS` for infomation

Thanks for the explanation. I hadn’t thought about that, but it seems reasonable.

I have now moved away from setting the defines via those variables, so I’m avoiding the problem described in my original post.