Windows build & test CI and fixes #134
Conversation
mortbopet
force-pushed
the
dev/mpetersen/windows_ci
branch
3 times, most recently
from
9c6174d to
e91f219
Compare
mortbopet
force-pushed
the
dev/mpetersen/windows_ci
branch
from
e91f219 to
216c6f4
Compare
|
I think I updated the require rule to the new name so next time I hope it updates the checks appropriately. |
mortbopet
force-pushed
the
dev/mpetersen/windows_ci
branch
from
844e39c to
8535d29
Compare
|
Currently blocked by antlr/antlr4#4738. |
|
@EpsilonPrime this PR also bumps the protobuf version to 29.3, required due to another MSVC issue that removed a definition for Let me know if you want that change factored out into a separate PR. |
|
I'm okay keeping it here if it passes. The new version doesn't appear to be negatively affecting the non-windows builds. |
Windows needs to a-priori know how to open a file (binary or text). If not, text-mode is assumed, which then will translate line endings `\n->\r\n`. This, in turn, will break the protobuf loader. This in turn means that windows can't rely on `loadPlan`s format detection, in case the underlying file is a binary file. This change adds adds a `forceBinary` flag to `loadPlan`, which must be used on Windows when providing binary files. `loadPlan` is used a few different places, and this doesn't pipe that argument in everywhere. Fixes have been added to an extent s.t., tests pass.
|
@EpsilonPrime Marking this as ready for review. Windows seems to be in a pretty good spot, with most tests passing. Unfortunately, there's a lingering issue here where a |
mortbopet
changed the title
find_vs.ps1is used to enter a visual studio development environment, which in turn, makesninjaavailable.This also includes a fix which i've been running with locally for a while... For some yet unknown reason, the googletest dependency within ANTLR4 (antlr4->googletest) applies incorrect assumptions about include path inside the gmock project. This only happens when building with MSVC. We can hot-fix this by injecting the correct paths to the target, after it's been defined.
Unfortunately, there's a lingering issue here where a std::any_cast exception occurs. I've spent a fair bit of time trying to track down the issue, but to no avail. I don't plan on using the textual format any time soon, so for the sake of progress, i've disabled the text-format related tests for now. After merging this PR, I'll create an issue to track it, in case some Windows user stumbles upon this in the future.