This is nice when messing around with the nix configuration, since
you'll often end up building rocksdb *many* times.
We shouldn't need to do anything to get the logs in CI because we're
calling `nix-build-and-cache ci` at the beginning
Without this, we're building a static rocksdb inside the rust-rocksdb
build script every time. As far as I know this doesn't change clippy's
behavior, but it does take a *long* time.
Because the nix rocksdb build depends on the jemalloc feature, you need
to use a different devshell when passing --all-features to cargo than
the default.
Some of the features affect nix dependencies, so we need to have a
full feature list available when constructing the nix derivation. This
incidentally fixes the bug where we weren't enabling jemalloc on rocksdb
in CI/devshells, because jemalloc is now a default feature. It does not
fix the more general class of that issue, where CI is performing an
`--all-features` build in a nix devshell built for default-features.
I am now passing `--no-default-features` to cargo, and having it use our
unified feature list rather than duplicating the unification inside cargo.
Without setting JEMALLOC_OVERRIDE, we end up linking to two different
jemalloc builds. Once dynamically, as a transitive dependency through
rocksdb, and a second time to the static jemalloc that tikv-jemalloc-sys
builds.
This fixes dynamically-linked jemalloc builds, for the reasons described
in <https://github.com/girlbossceo/conduwuit/pull/400#issue-2316700200>.
We inherited the disabled-by-default setting from conduit. Conduwuit
change it to enabled-by-default in [1]. This can make things confusing
for users migrating from conduwuit to grapevine, especially since we
currently do not log a warning when federation is disabled.
[1]: 24605e151d
Unfortunately we need to pull tracing-opentelemetry from git because
there hasn't been a release including the dependency bump on the other
opentelemetry crates.
`create_cf` already fails when the column family already exists, but
this gives us a much better error message; namely, it tells us what
column family name is at fault.
Also adds a utility for formatting an error message in addition to all
of its sources, i.e. errors that came before it that led to the current
error.
This helps us to provide better error messages to users by including
more information: both our own error message and all of the underlying
error messages, if any, instead of only one or the other.
`panic!()` (and things that invoke it, such as `expect` and `unwrap`)
produces terrible looking error messages and `std::process::exit()`
doesn't run destructors. Instead, we'll make a `try_main` that can
return a `Result` with a structured error type, but for now I'm going to
be lazy and just use `Box<dyn Error>`. Then, `main` will call it and
return the appropriate `ExitCode` value based on `try_main`'s `Result`.
This gives us the opportunity to produce good error messages and doesn't
violently terminate the program.
