[PATCH 2 of 4] Win32: handling of localized MSVC cl output

[Maxim Dounin]

Hello!

On Sat, Feb 11, 2023 at 05:30:39AM +0000, Pavel Pautov via nginx-devel wrote:

> > -----Original Message-----
> > From: nginx-devel <nginx-devel-bounces at nginx.org> On Behalf Of Maxim
> > Dounin
> > Sent: Thursday, February 9, 2023 20:33
> > 
> > Hello!
> > 
> > On Thu, Feb 09, 2023 at 06:55:22AM +0000, Pavel Pautov via nginx-devel wrote:
> > 
> > > The 'for 80x86' part of cl version (in auto/configure output)
> > > always felt odd. Given it's used in subsequent patch, can we at
> > > least strip localized 'for' from NGX_MSVC_VER? Having it in
> > > otherwise non-localized output of "nginx -V" doesn't seem right
> > > either.
> > 
> > The "nginx -V" output simply shows how the compiler identifies
> > itself.  The patch has no intention to change this, it just
> > ensures that output of localized MSVC cl versions is recognized by
> > nginx.  And, actually, I would rather object stripping the
> > details, since any aspects of compiler identification might be
> > important.
> 
> The patch effectively introduces localized strings into "nginx 
> -V" output and, I guess, I just don't see how that is useful. 
> The binary architecture can be deduced from binary itself and 
> random peace of localized string might not be enough for build 
> machine locale identification (and why bother with it, anyway).

The details are usually needed in case of compilation issues (so 
there will be no binary at all) or miscompilation (so you might 
need all the details to find out why it happened).  Further, 
deducing architecture from binary itself is not something readily 
available in most support cases.

Note well that we do the same for other compilers: any additional 
details following the version number are preserved by nginx and 
shown in the "nginx -V" output.  This is proven to be helpful in 
many practical cases.

> And here are some other localizations to consider:
> Microsoft (R) C/C++ 최적화 컴파일러 버전 19.29.30147(x64)
> 用于 x64 的 Microsoft (R) C/C++ 优化编译器 19.29.30147 版

Thanks for additional samples.  That's unfortunate that Microsoft 
uses so many variants of the compiler identification, especially 
given that nginx explicitly requests non-localized output as per 
POSIX, with LC_ALL=C.

> So, I'd suggest to introduce something like NGX_MSVC_VER_LINE 
> and then derive both NGX_MSVC_VER (which would contain only 
> dotted version number) and NGX_MACHINE from it.

See above for arguments against only the version number.

As for the additional ways to identify NGX_MACHINE based on the 
full cl output, I don't think it worth the effort.  It is not 
really needed except for x64 builds with OpenSSL assembler 
optimizations, which is not something nginx uses for standard 
builds.  Further, the simple approach as suggested in this patch 
series covers most of the practical cases.

If a more complete solution would be needed, a better approach 
might be to provide a way to manually specify NGX_MACHINE, or 
instead detect it by compile-only feature tests from predefined 
macros.  This is, however, outside of the scope of this patch 
series.

-- 
Maxim Dounin
http://mdounin.ru/