<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">On 11/2/23 22:18, å´ å›½ç’‹ wrote:<br>
</div>
<blockquote type="cite" cite="mid:SJ0PR14MB662693DB8807B36D2E2D825AB2A5A@SJ0PR14MB6626.namprd14.prod.outlook.com">
<div>If OpenJDK requires en-us environment, then nothing needs to
be changed. Please ignore this thread.</div>
</blockquote>
<p>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.</p>
<blockquote type="cite" cite="mid:SJ0PR14MB662693DB8807B36D2E2D825AB2A5A@SJ0PR14MB6626.namprd14.prod.outlook.com">>><br>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">
>> 1. Does JDK welcome localized Visual Studio?<br>
>> I read the file `make/autoconf/toolchains.m4` and
found the following comment:<br>
>> > elif test "x$TOOLCHAIN_TYPE" =
xmicrosoft; then<br>
>> > # There is no specific version flag, but
all output starts with a version string.<br>
>> > # First line typically looks something
like:<br>
>> > # Microsoft (R) 32-bit C/C++ Optimizing
Compiler Version 16.00.40219.01 for 80x86<br>
>> > # but the compiler name may vary
depending on locale.<br>
>> > COMPILER_VERSION_OUTPUT=`$COMPILER
2>&1 1>/dev/null | $HEAD -n 1 | $TR -d '\r'`<br>
>><br>
>> 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.<br>
</div>
</span></font></div>
</blockquote>
So far we have only received contributions for different western
type languages, so the current parsing logic has only been adapted
for that.<br>
<blockquote type="cite" cite="mid:SJ0PR14MB662693DB8807B36D2E2D825AB2A5A@SJ0PR14MB6626.namprd14.prod.outlook.com">
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">>> 2. How can the problem be
solved?<br>
>> 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 <br>
> then the issue can be solved.<br>
>> 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?)<br>
</div>
</span></font></div>
</blockquote>
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.<br>
<blockquote type="cite" cite="mid:SJ0PR14MB662693DB8807B36D2E2D825AB2A5A@SJ0PR14MB6626.namprd14.prod.outlook.com">
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">>> 3. What is the best
solution?<br>
>> According to MSVC reference, a solid way to get
the MSVC version and the target CPU is via predefined
macros.<br>
>> 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.<br>
>> 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.<br>
</div>
</span></font></div>
</blockquote>
<p>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.</p>
<p>/Erik<br>
</p>
</body>
</html>