[vcpkg] Set correct locale env variables.

[moritz-h]

vcpkg explicitly sets the env variable LC_ALL=C.UTF-8, see here.
But a system may also has the env variable LANGUAGE set which takes precedence if LC_ALL has a value set different than C. Therefore, vcpkg may runs with a system default locale which is not the intended C.UTF-8. This can lead to problems if ports try to parse any tool output and do not properly handle locales by themself (e.g. #43291).

Therefore, vcpkg should probably also handle the LANGUAGE env variable in any way. Options:

• Unset LANGUAGE
• set to some explicit English default
• Set LC_ALL=C (but this will loose UTF-8)

References:

• Ubuntu docs
• gettext docs

(This is a summary of a discussion with @BillyONeal on Discord starting here.)

[BillyONeal]

Given that you only saw this fail inside tbb, would it be appropriate for the tbb port to set LANGUAGE? EDIT: I see your outstanding PR already does this. Maybe that is the right fix overall.

[BillyONeal]

How about we just take your fix #43291 for now, and change the tool if we see more port(s) which do this. Getting localized messages but not breaking digit separators and stuff that other tools tend to depend on seems like a good thing TM.

[moritz-h]

To fix tbb #43291 is fully sufficient. This issue is not critical. It is more in the sense to be more definsive against potential edge cases and because the tbb issue was triggered as a combination of tbb and vcpkg both changing only selected env vars.

To give the full story:
The executed command is from tbb: gcc -xc -c /dev/null -Wa,-v -o/dev/null

My system default (I think this is Ubuntu default for localized install):
LC_ALL is unset, LANG=de_DE.UTF-8 LANGUAGE=de_DE:en
With this command output is localized.

Upstream TBB does LANG=C command. This gives english output even with LANGUAGE set to something different. So yes it's a tbb issue to just ignore env vars with higher precedence which should be fixed, but with system defaults it seems to "just work". Thats why upstream works currently.

Now what curretly breaks the vcpkg tbb build is vcpkg setting LC_ALL=C.UTF-8, so effectivly LC_ALL=C.UTF-8 LANG=C command is executed (with LANGUAGE being the system default). This output is localized. So vcpkg setting LC_ALL triggers that LANGUAGE is used at all. This does kind of feel unintended. I thought this may can be improved to be more defensive against incomplete libraries.

What I totally missed until now is the context that vcpkg-tool actually sets this at the beginning of its own main function, so probably this locale is meant for vcpkg-tool internal usage where localization is probably wanted and it's just a side effect that this env var bubbles down to cmake configuration of ports. I only looked at it from port perspective that ports should in the best case be build in an exact same state across any machines where localization is just an additional error factor and users do not see that output anyway despide in logfiles.
So its probably more complicated to think about this and solve this. Therefore, questionable if its worth the benefit and actually easier to fix broken ports directly like tbb now. Would otherwise go in a direction like should vcpkg_cmake_configure cleanup env vars overall for a mostly system independent port build (e.g. also with binary caching in mind across systems).