95dbf30fb9
All platforms: - rename scripts/ to tools/: Bazelisk expects to find its wrapper script (used by the Mac changes below) in tools/. Rather than have a separate scripts/ and tools/, it's simpler to just move everything into tools/. - wheel outputs and binary bundles now go into .bazel/out/dist. While not technically Bazel build products, doing it this way ensures they get cleaned up when 'bazel clean' is run, and it keeps them out of the source folder. - update to the latest Bazel Windows changes: - bazel.bat has been removed, and tools\setup-env.bat has been added. Other scripts like .\run.bat will automatically call it to set up the environment. - because Bazel is now on the path, you can 'bazel test ...' from any folder, instead of having to do \anki\bazel. - the bat files can handle being called from any working directory, so things like running "\anki\tools\python" from c:\ will work. - build installer as part of bundling process Mac changes: - `arch -arch x86_64 bazel ...` will now automatically use a different build root, so that it is cheap to switch back and forth between archs on a new Mac. - tools/run-qt* will now automatically use Rosetta - disable jemalloc in Mac x86 build for now, as it won't build under Rosetta (perhaps due to its build scripts using $host_cpu instead of $target_cpu) - create app bundle as part of bundling process Linux changes: - remove arm64 orjson workaround in Linux bundle, as without a readily-available, relatively distro-agonstic PyQt/Qt build we can use, the arm64 Linux bundle is of very limited usefulness. - update Docker files for release build - include fcitx5 in both the qt5 and qt6 bundles - create tarballs as part of the bundling process
2.1 KiB
This folder integrates Rust crates.io fetching into Bazel.
To add or update dependencies, ensure a local Rust environment is available
(eg source tools/cargo-env), then install cargo-raze:
cargo install cargo-raze --version 0.14.1
cargo install cargo-license
After adding/updating dependencies in ../rslib/Cargo.toml, change to this folder and run:
$ python update.py
or
$ REPIN=1 python update.py
The former will apply added crates and adjusted version numbers, while leaving most crate versions alone. The latter will also update pinned dependencies to their latest compatible versions.
Note: cargo-raze does not currently work when run from Windows, and nobody has investigated why yet. For now, you'll need a Mac or Linux machine, or will need to run update.py from within WSL.
A couple of crates need extra work to build with Bazel, and are listed in ../Cargo.toml. For example:
[package.metadata.raze.crates.pyo3.'*']
compile_data_attr = "glob([\"**\"])"
With minor version updates, you should not normally need to modify the entries in that file.
Because update.py modifies a lot of files in remote/, it makes it difficult to review in a PR, and the changes can sometimes break platforms like Windows. For this reason, please don't submit PRs that do minor version bumps - those will typically be done after stable releases. If you need a new crate for a feature you're working on, please raise it in an issue first.
Reqwest
Things are complicated with reqwest at the moment, because:
- we're using a fork to implement better timeouts for syncing
- we want to build it with different features on Linux (where we can't build a wheel that links to OpenSSL), and on other platforms.
For minor version bumps, update.py should take care of updating the versions of reqwest dependencies.
After making a big update to reqwest via an updated fork, the vendored BUILD.reqwest.* files may need updating. To do that, comment native-tls from the features in rslib/Cargo.toml and run update.py, and copy the file in remote/ over the old vendored file. Then comment the other two deps out, add native-tls back, and repeat the process.