mach does not recognize localized warnings

NEW
Unassigned

Status

Firefox Build System
General
5 years ago
2 months ago

People

(Reporter: Swatinem, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
When I’m building with a german locale, that makes gcc emit warnings in german, mach does not recognize them and the warnings summary and list is empty.

Maybe the best solution would be to just force LANG=C for all the build processes. Any objections?

(I’m on gcc 4.8 which also emits small source snippets, I hope thats not a problem?)

Comment 1

5 years ago
Forcing LANG=C might have other ramifications, such as developers not seeing errors in their native language. We should have mach detect the compiler warning more robustly. e.g. we could detect what compiler warnings look like during configure and use that to feed a parser.

What do German compiler warnings look like?
Component: mach → Build Config
+Masatoshi, who IIRC uses a localized compiler.
(Reporter)

Comment 3

5 years ago
47:19.07 /nosnap/mozilla-inbound/security/manager/ssl/src/nsIdentityChecking.cpp: In statischer Elementfunktion »static PRStatus nsNSSComponent::IdentityInfoInit()«:
47:19.07 /nosnap/mozilla-inbound/security/manager/ssl/src/nsIdentityChecking.cpp:1102:15: Warnung: Variable »rv« gesetzt, aber nicht verwendet [-Wunused-but-set-variable]
47:19.07      SECStatus rv;
47:19.07                ^

Thats a short example for german warnings.
GCC does give the -W… identifier since some more recent version, and also a small source snippet like I said.

I personally like the warnings in english and am always annoyed by GCCs localization, but you are right, there sure are devs who prefer to have them in their native locale.
|mach warnings-summary| and |mach warnings-list| work on localized MSVC.
Also, LANG=C will have no effect on MSVC.
(Reporter)

Comment 5

5 years ago
Changing the regexp in python/mozbuild/mozbuild/compilation/warnings.py#30
to `\s(warning|Warnung):\s` works for german warnings.

But its kind of silly to define every possible translation there.

Would using a very broad matching like `\s[^:]+:\s` lead to false positives?

Comment 6

5 years ago
Look at how GCC formats the strings. If the localized string is "{warning_translation}: <rest of warning info>" and not "{warning formatter}", then we could use a generic regexp easily.

We definitely don't want to be in the business of coding every translation.

There may also be modes that emit machine readable output. I know Clang has one. If we got everyone building through mach, we could rewrite the machine readable warnings into human friendly ones on the fly...
(Reporter)

Comment 7

5 years ago
Digging through the GCC code, I found that the whole "warning: " prefix is defined here:
https://github.com/mirrors/gcc/blob/b21ad49678f5d1ce845853354a67b7343135c31d/gcc/diagnostic.def#L37
and then translated

```
#: diagnostic.def:37
msgid "warning: "
msgstr "Warnung: "
```

So the colon itself is part of the translated string.

Also, as far as I skim GCCs code, I don’t see evidence of machine-readable output.

So what would you suggest?

Updated

2 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.