Commit Graph

27 Commits

Author SHA1 Message Date
Damien Elmes
72c7d64876 Fix compatibility with older macOS versions
https://forums.ankiweb.net/t/anki-2-1-50-qt5-wont-open/19091
2022-04-15 17:35:05 +10:00
Damien Elmes
95dbf30fb9 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-02-10 19:23:07 +10:00
Damien Elmes
f842ab7c9d switch convenience symlinks to .bazel/
Unfortunately 5efaf5a4be broke the Svelte
language tools - presumably having paths outside of the repo is confusing
them.

As a plan B, the symlinks have been shifted to a single subdir. Along
with some exclusions in the VS Code config, this should allow VS Code
to continue to work out of the box, but the docs will need updating
to reflect the extra work required for PyCharm/IntelliJ.

+ fix svelte-check execution on a system without node installed. It
still throws up some errors that are presumably caused by our multiple
rootDirs - not sure if there's an easy way to work around that.
2022-01-24 11:06:02 +10:00
Damien Elmes
5efaf5a4be move Bazel convenience symlinks outside of repo folder
The default symlink location can cause slowdowns and wasted CPU cycles
in VS Code and PyCharm/IntelliJ, as they try to watch Bazel's (large)
build folder for changes. The issue can be mostly ameliorated in VS Code
by excluding the symlinks using globs in settings like watcherExclude,
but the Rust extension doesn't support globs, so each folder needs to be
listed out separately. And because the product name symlink depends on
the name of the directory you're building from, we can't just include
the excludes in .vscode - it will depend on the folder the user is storing
things.

PyCharm and IntelliJ behave even worse here - they continue to monitor
for changes in all folders of the repo, even if those folders have been
marked as excluded in the project settings. Placing the folders into the
IDE-global Editor>File Types>Ignored Files And Folders works around this,
but again we run into troubles making this work out of the box, especially
with the product name in the symlink.

One option would be to turn the symlinks off completely. They are not
required for building, and for scripting/debugging, we can get the folder
locations via 'bazel info'. But with that approach, we would no longer
be able to symlink build products into the source tree, as we do for
things like the generated backend methods and translations, so we'd lose
code completion for them that way.

Another option would be to place the symlinks in .bazel/ inside the repo.
That solves the VS Code case (in conjunction with a workspace config file),
but doesn't fully fix IntelliJ/PyCharm.

The only remaining option I can see is to place the symlinks outside the
repo. Bazel won't expand ~ in the symlink path, so we can't use something
like ~/.cache/bazel/anki to place the files near the other build files.
So we end up having to have the files written to ../bazel/anki, in the
repo's parent folder. Not very clean, but I don't see a better alternative
at the moment.

.gitignore is still ignoring bazel-*, as currently bazel-dist and
bazel-pkg will be created when building/packaging. They should be fairly
innocuous, but we may want to rename them at one point.

Other changes:

- add missing symlink for pylib hooks
- add a sample .user.bazelrc file
2022-01-23 19:18:44 +10:00
Damien Elmes
67ee6f9c0e update to Rust 1.57 + latest rules_rust 2021-12-03 20:35:52 +10:00
Damien Elmes
bdbcb6d7aa default to a vendored copy of Python
Brings Python in line with our other dependencies, and means users
no longer need to install it prior to building, or deal with
issues caused by having the wrong version available.
2021-10-15 22:14:05 +10:00
Damien Elmes
e9c7b2287f bump minimum Python to 3.9 2021-10-04 15:05:15 +10:00
Damien Elmes
944b064e54 update Rust deps 2021-10-02 20:42:03 +10:00
Damien Elmes
d73852f272 use separate integration test for links
If we run into issues with unreliable network connections in the future,
we'll be able to mark the test as flaky so Bazel can retry it multiple
times.
2021-07-24 10:12:25 +10:00
Damien Elmes
b1dedb1b1f disable link check outside CI 2021-07-23 20:22:32 +10:00
Damien Elmes
d3062ceda4 fix release builds 2021-06-24 15:01:32 +10:00
Damien Elmes
1cc63f9267 update to latest rules_rust incremental compilation 2021-04-09 12:48:24 +10:00
Damien Elmes
6f7a4bf29e update rules_rust with worker refactor
If you were using the optional Rust worker support, please see the
change to development.md
2021-03-30 17:24:51 +10:00
Damien Elmes
89d249b3b6 update to the latest rules_rust + security framework update 2021-03-27 19:28:19 +10:00
Damien Elmes
dbcfaadd79 we no longer need to force CI to local 2021-03-21 00:25:59 +10:00
Damien Elmes
3c1fa68460 turn top bar dark when night mode enabled on macOS 2021-02-04 19:19:56 +10:00
Damien Elmes
ed7e709285 update pinned Bazel version to 4.0 release 2021-01-21 19:58:41 +10:00
Damien Elmes
68e3d55c17 typo 2020-12-29 15:26:06 +10:00
Damien Elmes
e948544b59 use local strategy for Svelte on CI
Allows some type errors to surface that were only being picked up
on Windows.

The root cause seems to be TypeScript picking up other .d.ts/.tsx
files in the same folder, which it can only do on Windows due to the
lack of sandboxing. On other platforms the other files can't be found,
and tsc changes the types into 'any'.

I experimented with modifying rules_svelte to build all .tsx files up
front and convert them to .d.ts in bulk, but ran into further issues
with conflicting types, as the typings in svelte2tsx seem to conflict
with Svelte's built-in types, and passing the dependencies in explicitly
causes them to be checked even though --skipLibCheck is passed in to
TypeScript.

Forcing sandboxing off is an ugly hack, and our best approach moving
forward may be to switch to ts_project for the Svelte generation -
it does appear that rules_nodejs favours it over ts_library anyway.
2020-12-29 14:50:33 +10:00
Damien Elmes
355e4cd519 use PYTHON_SYS_EXECUTABLE for setting path to Python 2020-12-23 21:53:13 +10:00
Damien Elmes
b80f33d14d document worker and disable it by default 2020-12-11 21:04:06 +10:00
Damien Elmes
fb680aa77e update rules_rust + persistent_worker 2020-12-10 15:35:37 +10:00
Damien Elmes
b55fd93cab manual tag on rslib was preventing clippy lints 2020-11-24 20:10:16 +10:00
Damien Elmes
e5059a5dff update Windows CI 2020-11-09 19:09:23 +10:00
Damien Elmes
f93f01b3e9 support user bazelrc 2020-11-04 22:11:28 +10:00
Damien Elmes
c179a2b45b extract version from defs.bzl; gate buildhash on optimized build 2020-11-04 14:02:08 +10:00
Damien Elmes
aea0a6fcc6 initial Bazel conversion
Running and testing should be working on the three platforms, but
there's still a fair bit that needs to be done:

- Wheel building + testing in a venv still needs to be implemented.
- Python requirements still need to be compiled with piptool and pinned;
need to compile on all platforms then merge
- Cargo deps in cargo/ and rslib/ need to be cleaned up, and ideally
unified into one place
- Currently using rustls to work around openssl compilation issues
on Linux, but this will break corporate proxies with custom SSL
authorities; need to conditionally use openssl or use
https://github.com/seanmonstar/reqwest/pull/1058
- Makefiles and docs still need cleaning up
- It may make sense to reparent ts/* to the top level, as we don't
nest the other modules under a specific language.
- rspy and pylib must always be updated in lock-step, so merging
rspy into pylib as a private module would simplify things.
- Merging desktop-ftl and mobile-ftl into the core ftl would make
managing and updating translations easier.
- Obsolete scripts need removing.
- And probably more.
2020-11-01 14:26:58 +10:00