This will likely install protobuf 3.21; in which case, you will get compilation errors unless you regenerate all of the protobuf files.

this will likely need to be updated with https://linear.app/comm/issue/ENG-1804 anyway. I guess I'm fine

However, no idea what nativeBuildInputs = (o.nativeBuildInputs or []) ++ [ prev.cmake ];

Actually, just use cmake to build c-ares

I think for now, I'll just cave in and have a section for installing homebrew + stuff that's not available on nixpkgs. Not sure how much I want to take on unbounded work :/

improvement

In addition to that:

• https://docs.rs/log/latest/log/ is the official logging facade, in which the tracing API is exposed
• https://github.com/env-logger-rs/env_logger/ is a popular implementation of logging, which allows you to set RUST_LOG to a logging value before launching your application.

the tests aren't running (and failing).

Default BUILD_TESTING to ON

https://linear.app/comm/issue/ENG-1799/dont-immediate-fail-if-tunnelbrokerini-is-missing is the spiritual successor to this

Agreed, the current paradigm should be extended.

better

better

better

This isn't necessary on the nix develop side, but this probably fixes the docker build as it has an older version of openssl available.

i think this makes sense as a separate change because i'll be moving a bunch of files and it'll clutter this diff. what do you think?

We should probably use a build rule so that it doesn't need to blindly call this each time. But blindly calling it isn't too terrible as cargo builds should be relatively quick after initial build

https://phab.comm.dev/D5084#148472 is still applicable

Send the apns message using the following library call from C++:

feel like the linting stuff should have been applied to the respective revisions. Also feel like the "create more revisions to apply feedback" is creating more churn for everyone, instead of applying the feedback in the original revision, then doing a rebase after applying the feedback.

better than panic'ing

This fixes the incorrect code from D5072.

protoc should be found if it's on the PATH. Otherwise some library messed up because the POSIX way to find something is through PATH.