Hello! On Sat, Feb 11, 2023 at 05:30:39AM +0000, Pavel Pautov via nginx-devel wrote:
> > -----Original Message----- > > From: nginx-devel <nginx-devel-boun...@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/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-devel
