Use the same JDK for building bazel and for its runtime.
Effectively, the former `toolchain_hostjdk8` java toolchain has been deprecated
and should no longer be used (in newer bazel)[1]:
```
default_java_toolchain(
name = "toolchain_hostjdk8",
...
)
```
[1]: 4fc4868065/tools/jdk/BUILD.tools (L384-L387)
* use default stdenv (clang 7)
* add no-arc.patch to make the xcode_locate tool compile without libarc-lite
* remove the `-mmacosx-version-min=10.9` flag from the bootstrap compile script
- bump protobuf to 3.13.0
- use recent rules_proto
- use recent bazel-skylib
- remove use of native.bind
Hopefully this is backward-compatible with bazel_3 and below
Bazel 4 is going to be a long term support release.
Latest version in NixPkgs so far was 3.3.1
There's a need for more recent version
https://github.com/NixOS/nixpkgs/issues/97497
All versions from 3.5.0 to 3.7.1 had some reproducibility issues
as noted in issue above, but there also seems to be
a working PR for 3.7.1 now at
https://github.com/NixOS/nixpkgs/pull/105439
Notable changes from bazel_3 setup:
- put python to default bash path
For autodetecting python toolchain
with strict action_env on and without this change
bazel would fail to autodetect host python.
There are some repos that define hermetic python
toolchains, but they aren't easy to use yet. Also
telling python paths to bazel isn't a 1-liner it
seems:
- action_env=PATH would affect cache
- declaring toolchain via BUILD&WORKSPACE files
is not per-user but more like per-repo and
affects cache too
Using python from nixpkgs shouldn't be too bad
in the lack of simpler hermetic python toolchain
options
- bazel_4.updater is bazel on `bazel query` to support
new constructs in WORKSPACE (load of vars, transitive
load etc). This is more robust but requires bazel
to run the updater, using bazel_3 for now. This is
only needed to bump package version, doesn't introduce
bazel_4 build dependency on bazel_3
https://blog.bazel.build/2020/11/10/bazel-4.0-announce.htmlhttps://blog.bazel.build/2020/11/10/long-term-support-release.htmlhttps://github.com/bazelbuild/bazel/issues/12455https://github.com/bazelbuild/bazel/releases/tag/4.0.0https://blog.bazel.build/2021/01/19/bazel-4-0.html
* use default stdenv (clang 7)
* add no-arc.patch to make the xcode_locate tool compile without libarc-lite
* remove the `-mmacosx-version-min=10.9` flag from the bootstrap compile script
Use the same JDK for building bazel and for its runtime.
Effectively, the former `toolchain_hostjdk8` java toolchain has been deprecated
and should no longer be used (in newer bazel)[1]:
```
# Deprecated, do not use.
# It will be removed after migration to Java toolchain resolution.
default_java_toolchain(
name = "toolchain_hostjdk8",
...
)
```
[1]: 4fc4868065/tools/jdk/BUILD.tools (L384-L387)
Fixes missing CoreFoundation declarations since bump to 3.19.3,
e.g. `error: unknown type name 'CFUUIDRef'`
ApplicationServices.h transitively includes CoreFoundation.h, but as we
patch ApplicationServices out of CMake, the CF symbols were not visible.
Previously this was not a concern, as they were not needed until
d250b67722
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
This fixes issues with building LibreSSL, which is required for the
NixOS tests: https://cmake.org/cmake/help/latest/release/3.19.html#id1
> CMake 3.19.0 compiles source files with the `LANGUAGE` property by
> passing an explicit language flag such as -x c. This is consistent
> with the property’s documented meaning that the source file is written
> in the specified language. However, it can break projects that were
> using the property only to cause the specified language’s compiler to
> be used. This has been reverted to restore behavior from CMake 3.18
> and below.
