langfingaz/anki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
f165576992
anki/.bazelrc

41 lines
1.4 KiB
Plaintext
Raw Normal View History

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 05:26:58 +01:00
common --enable_platform_specific_config
common --experimental_repository_cache_hardlinks
use PYTHON_SYS_EXECUTABLE for setting path to Python
2020-12-23 12:51:26 +01:00
# specify python path for pyo3 compile
update pinned Bazel version to 4.0 release
2021-01-21 10:41:20 +01:00
build:windows --action_env="PYTHON_SYS_EXECUTABLE=c:/python/python.exe"
use PYTHON_SYS_EXECUTABLE for setting path to Python
2020-12-23 12:51:26 +01:00
#build:linux --action_env="PYTHON_SYS_EXECUTABLE=/usr/local/bin/python3.8"
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 05:26:58 +01:00
turn top bar dark when night mode enabled on macOS
2021-02-04 10:07:34 +01:00
# only affects the ankihelper library
#build:macos --macos_cpus=x86_64,arm64
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 05:26:58 +01:00
# runfiles are off by default on Windows, and we need them
build --enable_runfiles
# skip the slow zip step on Windows, as we have symlinks
build:windows --build_python_zip=false
# record version/build hash
build --workspace_status_command='bash ./scripts/status.sh'
# run clippy when compiling rust in test mode
manual tag on rslib was preventing clippy lints
2020-11-24 11:10:16 +01:00
test --aspects=@io_bazel_rules_rust//rust:rust.bzl%rust_clippy_aspect --output_groups=+clippy_checks
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 05:26:58 +01:00
# print output when test fails
test --test_output=errors
# don't add empty __init__.py files
build --incompatible_default_to_explicit_init_py
# faster for .ui file generation, but may sacrifice correctness
#--genrule_strategy=standalone
support user bazelrc
2020-11-04 13:11:28 +01:00
update Windows CI
2020-11-09 08:52:33 +01:00
build:ci --show_timestamps --isatty=0 --color=yes --show_progress_rate_limit=5
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 05:50:33 +01:00
# the typescript generation hack in rules_svelte is not hermetic, and
# converts declared types in props to 'any' if it's not run locally.
typo
2020-12-29 06:26:06 +01:00
# Fixing it properly will probably require moving the Svelte rules to
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 05:50:33 +01:00
# ts_project()
build:ci --strategy Svelte=local
support user bazelrc
2020-11-04 13:11:28 +01:00
try-import %workspace%/user.bazelrc
Reference in New Issue Copy Permalink