Make IntegratedSnarlFinder the default again #2785
Conversation
|
@adamnovak can you please switch over |
adamnovak
force-pushed
the
new-default-snarls
branch
from
a88ef6d
to
0a1f8ae
Compare
adamnovak
changed the title
adamnovak
force-pushed
the
new-default-snarls
branch
from
0a1f8ae
to
3fb3f52
Compare
adamnovak
force-pushed
the
new-default-snarls
branch
from
3fb3f52
to
68d97a8
Compare
|
This is now failing because of a Mac Travis problem that also affects master. That problem is in turn due to Protobuf's I'm not quite sure what to do about that. Maybe always rebuild the Protobufs if we see 3.12.3? |
|
The real problem for our CI was this: Homebrew/homebrew-core#58229 Homebrew changed which flavor of 3.12.3 they ship, but kept the version number at 3.12.3. So now we look, see out headers were generated by what appears to be the right Protobuf version, don't regenerate them, and fail. |
When Homebrew shipped Homebrew/homebrew-core#58229 they broke our CI by shipping a Protobuf 3.12.3 that is not compatible with headers generated by the Protobuf 3.12.3 that they previously shipped. Since this particular Protobuf version is still [actively on fire](protocolbuffers/protobuf#7632), if we're trying to use it we should just rebuild the headers with the Protobuf we actually have.
|
Now because we have to rebuild everything that depends on the Protobuf headers, we're hitting the timeout on the build. This approach may not work for Travis; maybe we just need to clear the caches instead. |
We have to just ignore Proto 3.12.3 or we will rebuild completely multiple times.
|
Yeah it turns out we can't clear out Protobuf headers every time we run make and still pass the Travis tests in time. I cleared the cache for this PR, but other busted PRs will need their caches cleared because I don't think we can usefully solve the problem via the build system. |
This reverts commit 9e54402.