Boost Is Planning A Move To CMake

[BeardedGNUFreak]

It's a Python bug

What a surprise!

Hey, be thankful the turd that is Meson at least isn't written in Mono.

[arteast]

There's no reason to use UTF8 in a build system.

Build tools can do their jobs entirely in 8-bit binary, they have no need to understand what a file name is or how it is constructed.

Build systems obviously need to know how to split filenames into components, and how to combine them back. At very least they need to know what path separators are. Now, can build system ignore encoding of the filename components?
Yes, as long as all the OS APIs can correctly consume filenames encoded in the same encoding the a build file happens to be in. We can probably assume build file is going to be utf-8. On Linux/MacOS/BSD you are golden (provided console is utf-8 which itshould, or you are asking for a lot of trouble anyway).

But there is one big exception called Windows. In Windows you've got Unicode API by default (actually UTF-16), or you can specifically opt in for MBCS API which under the hood translates to the unicode version based on program's current locale - which is not utf-8. And no you cannot set UTF-8 locale. So, for build system to be viable on Windows it has to decode UTF-8 from the build files itself, and then pass UTF-16 encoded filenames to the API.

Also, build systems I saw provide some functionality on string manipulation, and those better be utf-8 aware as well ("I wanted to get first 8 characters of that string, not 3 and a half ").

[carewolf]

Build systems obviously need to know how to split filenames into components, and how to combine them back. At very least they need to know what path separators are. Now, can build system ignore encoding of the filename components?
Yes, as long as all the OS APIs can correctly consume filenames encoded in the same encoding the a build file happens to be in. We can probably assume build file is going to be utf-8. On Linux/MacOS/BSD you are golden (provided console is utf-8 which itshould, or you are asking for a lot of trouble anyway).

But there is one big exception called Windows. In Windows you've got Unicode API by default (actually UTF-16), or you can specifically opt in for MBCS API which under the hood translates to the unicode version based on program's current locale - which is not utf-8. And no you cannot set UTF-8 locale. So, for build system to be viable on Windows it has to decode UTF-8 from the build files itself, and then pass UTF-16 encoded filenames to the API.

Also, build systems I saw provide some functionality on string manipulation, and those better be utf-8 aware as well ("I wanted to get first 8 characters of that string, not 3 and a half ").

Actually on case-insensitive systems, they need full Unicode support to do normalized case-insensitive comparisons. If I remember correctly it is even done different in macOS and Windows.