Currently we disable //tests/mappings:utf8_manifest_test on windows.
It is enabled for macOS, but fails for me when building on a case sensitive file system.
The problem for macOS is related to handling of some characters in paths. macOS uses an alternate encoding, so our expected paths vary from what we get. You can see the difference in our normalized encoding of "sübdir/2-λ". On macos, instead of getting a single glyph, you get an encoding of 'u' followed by a "put an umlat on the previous character.
Perhaps, in the writers, we should take the destination path and run it throught
unicodedata.normalize('NFD', ) to get the more common representation to write
into the tar or zip file.
It's a pity we can't do that in starlark.
Currently we disable //tests/mappings:utf8_manifest_test on windows. It is enabled for macOS, but fails for me when building on a case sensitive file system. The problem for macOS is related to handling of some characters in paths. macOS uses an alternate encoding, so our expected paths vary from what we get. You can see the difference in our normalized encoding of "sübdir/2-λ". On macos, instead of getting a single glyph, you get an encoding of 'u' followed by a "put an umlat on the previous character.
This may need to be fixed in Bazel rather than here, I am just gathering data.