On 11/2/23 22:18, 吴 国璋 wrote:
If OpenJDK requires en-us environment, then nothing needs to be
changed. Please ignore this thread.
I should clarify this a bit. We aren't against making the build work on
different locales, but most of us are unable to verify that it keeps
working on anything by US-English. If you are willing to put in the work
to make it work in a Chinese environment, and the set of changes
required seem reasonable, we would accept that contribution. Just be
prepared to maintain that support over time, as it's quite likely that
future changes may break it.
>>
>> 1. Does JDK welcome localized Visual Studio?
>> I read the file `make/autoconf/toolchains.m4` and found the
following comment:
>> > elif test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
>> > # There is no specific version flag, but all output starts
with a version string.
>> > # First line typically looks something like:
>> > # Microsoft (R) 32-bit C/C++ Optimizing Compiler Version
16.00.40219.01 for 80x86
>> > # but the compiler name may vary depending on locale.
>> > COMPILER_VERSION_OUTPUT=`$COMPILER 2>&1 1>/dev/null | $HEAD
-n 1 | $TR -d '\r'`
>>
>> Therefore, it can be inferred that JDK knows that there are
different localizations of Visual Studio and is ready for them. JDK
thinks that maybe there will be different names of "Optimizing
Compiler" or others. However, in some languages, the whole structure
of the sentence is completely different, not just the names.
So far we have only received contributions for different western type
languages, so the current parsing logic has only been adapted for that.
>> 2. How can the problem be solved?
>> One solution is to change the way to parse the output of `cl.exe`.
For example, JDK treat the last word separated by a blank as the
target CPU, which is "x64" in English environment but "版" in Chinese
environment. (`make/autoconf/toolchain.m4`, Lines 983 to 997.) We may
use `grep` command to search for "x64" directly, and
> then the issue can be solved.
>> However, this solution is not good enough, because it is also based
on parsing the output, which is intended to be read by human, not by
scripts. (What if "x64" is changed into "64-bit" or "64 位" in a future
version?)
If the output changes, we adapt the regex. We need explicit changes to
support a new major version of Visual Studio anyway, so it would be done
as part of those changes. The likelihood of it changing in a minor
update is basically non existent.
>> 3. What is the best solution?
>> According to MSVC reference, a solid way to get the MSVC version
and the target CPU is via predefined macros.
>> To get the MSVC version, we can use `_MSC_VER`. When Visual Studio
2019 is used, the macro evaluates between 1920 and 1929. When Visual
Studio 2022 is used, the macro evaluates above 1930.
>> To get the target CPU, we can use `_M_X64`, `_M_IX86`, `_M_ARM` and
`_M_ARM64`. For example, if the target CPU is x64, `_M_X64` will be
evaluated to 100, and the other three macros are undefined.
Using the C preprocessor may work, but as Robbin pointed out, we would
prefer if you used one of the Autoconf macros for generating the input
files and running it if you were to go that route. However, I think I
would prefer if you could just adapt the current logic for parsing the
compiler version output.
/Erik
