GlareDB is developed primarily in Rust, and building from source requires that a Rust toolchain be setup, and accessible in your path. The easiest way to get started with Rust is by using rustup. All distributed release binaries of GlareDB use the latest stable Rust toolchain.
protoc is also required to be in your path when building GlareDB.
Building the CLI from source is just a simple cargo build:
$ cargo build --release --bin glaredb
The binary will be located at ./target/release/glaredb
The --release flag may be omitted to make the build quite a bit quicker.
However this results in a larger and slower binary, and should only be used when
during development. When benchmarking, always pass the --release flag.
In addition to the above prerequisites, building the Python bindings requires maturin to be in your path, as well as a venv set up.
To create the virtual env:
$ python -m venv crates/glaredb_python/venv
Activate the virtual env:
$ cd crates/glaredb_python
$ source ./venv/bin/activate
# OR
$ export VIRTUAL_ENV="<path-to-venv-dir>"
$ export PATH="$VIRTUAL_ENV/bin:$PATH"
Build the release bindings (assuming the current directory is
./crates/glaredb_python):
$ maturin build --release --out dist
The wheel will be located at ./dist/glaredb-....
--release may be omitted for a faster build, but this should only be done during
development.
In addition to the above prerequisites, building the WebAssembly bindings requires wasm-pack to be in your path.
Build the release bindings:
$ wasm-pack build crates/glaredb_wasm/ --scope glaredb
The wasm blobs and related javascript will be located at ./crates/glaredb_wasm/pkg.
The --dev flag may be use for a faster build. This should only be done during
development.
Compiling binaries with the --release flag (or for WebAssembly, omitting the
--dev flag) will result in the fastest binary and typically smallest binary.
Debug binaries are slower and larger. However they're quick to build, and have additional runtime assertions enabled. When debugging an issue, reproducing it with a debug binary often times provides more information about what went wrong. All tests (unit tests and SQL Logic Tests) are ran in debug mode.