Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
/utf-8 is equivalent to /source-charset:utf-8 /execution-charset:utf-8. Now that all source files (except for included third-party headers outside of this repository) are in UTF-8, we must set source-charset to utf-8, because otherwise the default (on our build machines) is CP-1252. (The compiler does not auto-detect UTF-8 source files unless they have a UTF-8 BOM, which we do not use.) The execution charset determines how (non-wide) string literals are encoded in the executable binary. UTF-8 is usully appropriate for our string constants (such as property names and values), because JNI and SWIG assume UTF-8 and C/C++ library functions work with UTF-8. Our only examples of non-ASCII characters in string literals (at least among the files recently converted to UTF-8) are 8-bit characters from iso-8859-1 (latin1) (there are one or two exceptions that are insignificant). These, if exposed to the CMMCore API (to Java or Python) were presumably working just because UTF-8 is a superset of iso-8859-1 (but not of CP-1252) -- they were stored in the binary as CP-1252 but treated by SWIG-generated code as UTF-8. (Use of non-ASCII characters in property names and other such strings is still not a very good idea, but we don't want to change names that will invalidate configuration files.) As far as I can tell, the conversion of source code to UTF-8 and the introduction of /utf-8 do not interact with the project Character Set setting (Unicode or Multi-byte), which only control whether the Win32 API functions default to the "A" or "W" version. Incidentally, use of /utf-8 also helps to prepare for the switch to Meson, which adds /utf-8 by default.
- Loading branch information