GN Win11/VS2022 unit test failures?

[Charles Nicholson]

Hi GN devs-

I'm building on a fully up-to-date Win11 machine with VS2022 and Python 3.10 installed. I open up a VS2022 64-bit developer command prompt and build GN per the web page instructions. I'm using the pre-built ninja v1.11.1 from the ninja releases page on github.

I get a ton of link warnings about empty PDB files, but whatever- gn.exe and gn_unittests.exe do link, and gn.exe does run and give me the "hey, you didn't give me a subcommand" error, indicating that it's at least sane.

The unit tests fail spectacularly though, FormatTest.001 to FormatTest.084 (command_format_unittest.cc) all fail unhelpfully with "expected == out", and then "ImportantFileWriterTest.Basic" also fails.

I'm following the build steps exactly as documented, and I'm on the pristine head of the main branch as of today.

Is this a known issue? Am I using an OS / VS version newer than what GN builds under CI? I haven't tried debugging or using this gn.exe yet; I figured I'd ask first.

Thanks,

Charles

Screenshots attached for posterity:

[Brett Wilson]

I don't have a Windows box convenient to check right now. But given that it looks like basically all the format tests are failing, my suspicion is that there's a line ending difference.

I believe the build expects line endings to be unchanged from the repo (so Unix, I think), maybe your git is configured to convert text files to Windows line endings?

Brett

[Charles Nicholson]

Wow, that's almost certainly the issue, thanks. I'm happy to file a bug about making those tests less fragile; it's pretty common in my experience for people to configure git to convert to native-OS CR/LF options...

[Brett Wilson]

GN grew out of Chromium and we always had a policy that the files should be unchanged during checkout to reduce complexity (in practice, whatever was the less common configuration was always broken).

I think we should keep GN with the same policy, but if anybody wants to submit a patch to update the documentation or error messaging to help people with that case, it might be nice.

Brett

[Charles Nicholson]

Sure, but in this case it's just a simple matter of right-trimming the CR/LF bytes off of the ends of whatever strings you're comparing in your unit tests, right? Doesn't that still provide the same semantic correctness guarantees you're testing for, without making users navigate off-the-beaten-path git settings?

Put another way, testing for OS-specific CR/LF terminators might be considered a bug in the tests themselves...

[K. Moon]

That seems fragile compared to just enforcing that the files are always byte-for-byte identical with what's in the Git repo.

[K. Moon]

(That said, .gitattributes can programmatically enforce line endings for a given repository.)

[Charles Nicholson]

If everyone's comfortable with the unit tests harnessing both GN's functionality _and_ the client's version control system, I'll just assume that the head of main works and not worry about the failing unit tests. It would be nice if this were documented, though; I wouldn't have wasted your time :)

[Brett Wilson]

It looks like there's a git setting in the .gitattributes file we can specify so people get the correct line endings no matter their local settings. I'll try to set that.

Brett