Cannot configure on Windows in Chinese Environment

[erik.joelsson at oracle.com]

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/20231103/e3e82299/attachment.htm>