Cannot configure on Windows in Chinese Environment

[吴 国璋]

If making the build work on different locales is accepted, then we can further discuss on this topic.

I would like to implement this with C macros instead of parsing the output, because the MSVC reference includes the C predefined macros, but does not include the output format.

In fact, Visual Studio supports 14 language packs, and I only know how cl.exe presents itself in English and Chinese, maybe also French. Maybe the sentence structure is also different in Korean or Japanese, I am not sure. With C macros the implementation will be less impacted by locale and more stable.

From: erik.joelsson at oracle.com<mailto:erik.joelsson at oracle.com>
Sent: 2023年11月3日 21:04
To: 吴 国璋<mailto:zcxsythenew at outlook.com>; David Holmes<mailto:david.holmes at oracle.com>; build-dev at openjdk.org<mailto:build-dev at openjdk.org>
Subject: Re: Cannot configure on Windows in Chinese Environment

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20231104/907fed34/attachment-0001.htm>