updates to the build process and binary bundles
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
2022-01-30 01:50:14 +01:00
|
|
|
# Building and running Anki in Docker
|
2021-10-15 02:41:15 +02:00
|
|
|
|
updates to the build process and binary bundles
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
2022-01-30 01:50:14 +01:00
|
|
|
This is an example Dockerfile contributed by an Anki user, which shows how Anki
|
|
|
|
can be both built and run from within a container. It works by streaming the GUI
|
|
|
|
over an X11 socket.
|
2021-10-23 11:45:07 +02:00
|
|
|
|
updates to the build process and binary bundles
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
2022-01-30 01:50:14 +01:00
|
|
|
Building and running Anki within a container has the advantage of fully isolating
|
|
|
|
the build products and runtime dependencies from the rest of your system, but it is
|
|
|
|
a somewhat niche approach, with some downsides such as an inability to display natively
|
|
|
|
on Wayland, and a lack of integration with desktop icons/filetypes. But even if you
|
|
|
|
do not use this Dockerfile as-is, you may find it useful as a reference.
|
|
|
|
|
|
|
|
Anki's Linux CI is also implemented with Docker, and the Dockerfiles for that may
|
|
|
|
also be useful for reference - they can be found in `.buildkite/linux/docker`.
|
2021-10-15 02:41:15 +02:00
|
|
|
|
|
|
|
# Build the Docker image
|
|
|
|
|
|
|
|
For best results, enable BuildKit (`export DOCKER_BUILDKIT=1`).
|
|
|
|
|
|
|
|
When in this current directory, one can build the Docker image like this:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
docker build --tag anki --file Dockerfile ../../
|
|
|
|
```
|
|
|
|
|
|
|
|
When this is done, run `docker image ls` to see that the image has been created.
|
|
|
|
|
|
|
|
If one wants to build from the project's root directory, use this command:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
docker build --tag anki --file docs/docker/Dockerfile .
|
|
|
|
```
|
|
|
|
|
|
|
|
# Run the Docker image
|
|
|
|
|
|
|
|
Anki starts a graphical user interface, and this requires some extra setup on the user's
|
|
|
|
end. These instructions were tested on Linux (Debian 11) and will have to be adapted for
|
|
|
|
other operating systems.
|
|
|
|
|
|
|
|
To allow the Docker container to pull up a graphical user interface, we need to run the
|
|
|
|
following:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
xhost +local:root
|
|
|
|
```
|
|
|
|
|
|
|
|
Once done using Anki, undo this with
|
|
|
|
|
|
|
|
```bash
|
|
|
|
xhost -local:root
|
|
|
|
```
|
|
|
|
|
|
|
|
Then, we will construct our `docker run` command:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
docker run --rm -it \
|
|
|
|
--name anki \
|
|
|
|
--volume $HOME/.local/share:$HOME/.local/share:rw \
|
|
|
|
--volume /etc/passwd:/etc/passwd:ro \
|
|
|
|
--user $(id -u):$(id -g) \
|
|
|
|
--volume /tmp/.X11-unix:/tmp/.X11-unix:rw \
|
|
|
|
--env DISPLAY=$DISPLAY \
|
|
|
|
anki
|
|
|
|
```
|
|
|
|
|
|
|
|
Here is a breakdown of some of the arguments:
|
|
|
|
|
2021-10-23 07:34:08 +02:00
|
|
|
- Mount the current user's `~/.local/share` directory onto the container. Anki saves things
|
2021-10-15 02:41:15 +02:00
|
|
|
into this directory, and if we don't mount it, we will lose any changes once the
|
|
|
|
container exits. We mount this as read-write (`rw`) because we want to make changes here.
|
|
|
|
|
|
|
|
```bash
|
|
|
|
--volume $HOME/.local/share:$HOME/.local/share:rw
|
|
|
|
```
|
|
|
|
|
2021-10-23 07:34:08 +02:00
|
|
|
- Mount `/etc/passwd` so we can enter the container as ourselves. We mount this as
|
2021-10-15 02:41:15 +02:00
|
|
|
read-only because we definitely do not want to modify this.
|
|
|
|
|
|
|
|
```bash
|
|
|
|
--volume /etc/passwd:/etc/passwd:ro
|
|
|
|
```
|
|
|
|
|
2021-10-23 07:34:08 +02:00
|
|
|
- Enter the container with our user ID and group ID, so we stay as ourselves.
|
2021-10-15 02:41:15 +02:00
|
|
|
|
|
|
|
```bash
|
|
|
|
--user $(id -u):$(id -g)
|
|
|
|
```
|
|
|
|
|
2021-10-23 07:34:08 +02:00
|
|
|
- Mount the X11 directory that allows us to open displays.
|
2021-10-15 02:41:15 +02:00
|
|
|
|
|
|
|
```bash
|
|
|
|
--volume /tmp/.X11-unix:/tmp/.X11-unix:rw
|
|
|
|
```
|
|
|
|
|
2021-10-23 07:34:08 +02:00
|
|
|
- Pass the `DISPLAY` variable to the container, so it knows where to display graphics.
|
2021-10-15 02:41:15 +02:00
|
|
|
|
|
|
|
```bash
|
|
|
|
--env DISPLAY=$DISPLAY
|
|
|
|
```
|
|
|
|
|
|
|
|
# Running Dockerized Anki easily from the command line
|
|
|
|
|
|
|
|
One can create a shell function that executes the `docker run` command. Then one can
|
|
|
|
simply run `anki` on the command line, and Anki will open in Docker. Make sure to change
|
|
|
|
the image name to whatever you used when building Anki.
|
|
|
|
|
|
|
|
```bash
|
|
|
|
anki() {
|
|
|
|
docker run --rm -it \
|
|
|
|
--name anki \
|
|
|
|
--volume $HOME/.local/share:$HOME/.local/share:rw \
|
|
|
|
--volume /etc/passwd:/etc/passwd:ro \
|
|
|
|
--user $(id -u):$(id -g) \
|
|
|
|
--volume /tmp/.X11-unix:/tmp/.X11-unix:rw \
|
|
|
|
--env DISPLAY=$DISPLAY \
|
|
|
|
anki "$@"
|
|
|
|
}
|
|
|
|
```
|