Commit Graph

136 Commits

Author SHA1 Message Date
Uri Baghin
b8ab4451b5 bazel-buildtools: 0.28.0 -> 0.29.0 2019-09-11 15:17:07 +10:00
Vladimír Čunát
4aad2947f8
Merge branch 'master' into staging-next 2019-09-04 11:00:56 +02:00
Guillaume Bouchard
67904dccbb bazel: 0.28.1 -> 0.29.0
- Upgraded dependencies
  - dependencies script upgraded to take into account new WORKSPACE
    rules
- Tests now depends on the `distdir`

Runtime bazel now also depends on the `distdir` setting which appears
in the global configuration file. This increases the bazel closure
size by 85 MO for stuffs which can normally be downloaded at runtime
by bazel. However, any invocation of `buildBazelPackage` (such as in
`bazel-watcher`) may fail in nix sandbox if theses files are not
available at runtime.

If this overhead is too important, we may later evolve to a finer
grained solution, where buildBazelPackage declares the list of
necessary dependencies.
2019-09-03 13:12:53 +02:00
Frederik Rietdijk
ad1d58c622 Merge staging-next into staging 2019-08-31 10:04:20 +02:00
Frederik Rietdijk
fc74ba8291 Merge master into staging-next 2019-08-31 09:50:38 +02:00
Andreas Herrmann
1bf70fd2f1 bazel: cctools runtime dependency on darwin (#66724)
The bazel build patches paths like `/usr/bin/install_name_tool` to refer
to `${cctools}/bin/install_name_tool` instead. If the corresponding
runtime dependency is not denoted, then darwin users can encounter "file
not found" errors, e.g. when they fetch bazel from a binary cache and
don't have `cctools` in their own nix store.
2019-08-30 22:35:33 -06:00
volth
35d68ef143 treewide: remove redundant quotes 2019-08-26 21:40:19 +00:00
volth
c814d72b51 treewide: name -> pname 2019-08-17 10:54:38 +00:00
Frederik Rietdijk
fe9a3e3e63 Merge staging-next into staging 2019-08-17 09:39:23 +02:00
Andreas Herrmann
f426173e30 bazel: Fix python stub template
The shebang in the python stub template was incorrectly patched to
```
<store-path>/bin/env python
```
instead of
```
<store-path>/bin/python
```

The reason was that `patchShebangs` was called with `--replace` which is
an unknown argument.
```
patching script interpreter paths in src/main/java/com/google/devtools/build/lib/bazel/rules/python/python_stub_template.txt --replace /usr/bin/env python /nix/store/w7gsq8v86hni4ynaqgwwlnlny115ylng-python3-3.7.4/bin/python
find: unknown predicate `--replace'
```

Using `substituteInPlace` instead resolves that issue.

The wrong shebang caused failures of `py_binary` targets due to `python`
not being in `PATH` in certain circumstances.
2019-08-16 18:55:45 +02:00
volth
46420bbaa3 treewide: name -> pname (easy cases) (#66585)
treewide replacement of

stdenv.mkDerivation rec {
  name = "*-${version}";
  version = "*";

to pname
2019-08-15 13:41:18 +01:00
Wael Nasreddine
b3668d68a2
bazel: 0.28.0 -> 0.28.1 (#66402) 2019-08-09 17:30:06 -07:00
Nikolay Amiantov
a956694aba buildBazelPackage: clear markers
Turns out markers are non-deterministic after all and even our patching still
doesn't solve this problem completely. For example (tensorflow deps, this is a
complete diff so actual dependencies don't differ):

30509c30509
< bc527ff00916b15caee38793bca8f294c748df4a256de55c5199281be0489e73  result/@bazel_skylib.marker
---
> 4e0303e815c78df1e43d4b88dfe65e73046e0c6157fb10aa9a4e8b910113cd9c  result/@bazel_skylib.marker
31045c31045
< fa13d04b2316214c3b4008b52546c2d5b633e006f6f019d597bb3f9745bacf7b  result/@bazel_toolchains.marker
---
> b36174bf5535e5157801b6de30c35ee03a03fe57766306393c3d65dd65cbebf4  result/@bazel_toolchains.marker
31144c31144
< b0ce4a3ac29ac22528336dd3a54b5b7af9ecc43bef2a2630713c1981a5cbbb51  result/@build_bazel_rules_swift.marker
---
> 7492528068ec4f8e7ace2ecf8f933ec4e1b2235bd7426ce6f70177919f1cd05e  result/@build_bazel_rules_swift.marker
36245c36245
< be2993536a8233d63251b664caf35b1e7cd57d194ab2a39a293876c232d6bbd0  result/@io_bazel_rules_closure.marker
---
> b6655cc3f2c78525e5a724d8a4e93b1e7f09f1e09fc817d231109e7f39103e88  result/@io_bazel_rules_closure.marker
36329c36329
< 087bc674c9509dfe157400d111db4a13eeb45fc76aeccd490cee9aad6771ecad  result/@io_bazel_rules_docker.marker
---
> f920ec07315ec71e800b05cd22b2a341c0a80807c6e335ee81739b13c532b422  result/@io_bazel_rules_docker.marker
79544d79543
< 85893a05a817036c61f6cd9f8247757baa1654f473c494ce4fc5253c2bbd2790  result/@platforms.marker

And here's an example of differences:

$ cat result-a/@bazel_skylib.marker
7dc7472d37424ba5ec6a5532765bc911
$MANAGED
cat result-b/@bazel_skylib.marker
a8f3f577798201157128e8e9934c4705
$MANAGED

Instead of trying to patch these markers further we now completely clear them.
Nix hacks for ignoring markers are restored and expanded so that we don't even
attempt to parse the marker.
2019-07-31 11:28:06 +03:00
Nikolay Amiantov
7b828532b9 bazel-deps: 2019-02-01 -> 2019-07-11, mark as broken
Also drop preInstall cleanup for dependencies. The reason is while it's more
thorough than default cleanup in buildBazelPackage if such a problem happens we
should fix buildBazelPackage instead. Perhaps even move this (awesome!) snippet
there but it's very slow-running so we'd rather attempt to fix it in other
ways.

Anyway after an update at least .deps build, checked with `nix-build -A --check`.
2019-07-25 17:40:46 +02:00
Nikolay Amiantov
969aec30b6 bazel-remote: mark as broken 2019-07-25 17:40:46 +02:00
Profpatsch
fdee6f4fae bazel: disable dm-sonnet downstream test 2019-07-25 13:27:45 +02:00
Profpatsch
63e0b8b3f9 bazel: execute dm-sonnet test only on linux 2019-07-25 13:27:45 +02:00
Timo Kaufmann
e7e70b7073 bazel: add fixed output test case
Feels like a horrible hack, but it should make sure that downstream
hashes are preserved between bazel versions.
2019-07-25 13:27:45 +02:00
Lefteris Kritikos
6d25177ca8 bazel-buildtools: 0.22.0 -> 0.28.0 2019-07-24 18:57:52 +02:00
Nikolay Amiantov
4dad0ae560 buildBazelPackage: cleanup hacks and enforce them for all builds
Timestamp verification skip is no longer needed (not sure why). Generally we
better off always using the environment hack for all packages because that
ensures all NIX_* flags are correctly applied.

One possible improvement in future is to filter only NIX_* variables to
passthru in Bazel.
2019-07-17 10:40:38 +03:00
Wael Nasreddine
c4813515ca
bazel: drop absolute Python path (#64903)
Without this Bazel always picks Python 3 which breaks Python 2 packages.
Strangely enough just dropping this patch works, with all `bazel.tests`
passing.
2019-07-16 20:17:27 -07:00
Guillaume Bouchard
950da6263f bazel: 0.27.0 -> 0.28.0 2019-07-16 17:43:18 +02:00
Nikolay Amiantov
bd98f3521c bazel: drop absolute Python path
Without this Bazel always picks Python 3 which breaks Python 2 packages.
Strangely enough just dropping this patch works, with all `bazel.tests`
passing.
2019-07-16 15:40:03 +03:00
Guillaume Bouchard
d363da72cc bazel: Use --distdir for prefetched repositories
--distdir is now used in the installCheckPhase for prefetched
  repositories. That's simpler, more robust and easier to extend in
  the future.

Note that `name` argument of fetchurl was removed because it changed
the basename of the generated file and bazel uses this basename for
its cache behavior.
2019-07-12 22:32:01 +02:00
Wael Nasreddine
7f69cab8a6
bazel: add a test asserting java and java proto (#63927) 2019-07-01 21:18:02 -07:00
Wael Nasreddine
c49b7f64d1
bazel: fix the compilation of .proto on Darwin (#63879)
On Darwin, the last argument to GCC is coming up as an empty string.
This is breaking the build of proto_library targets. However, I was not
able to reproduce with the example cpp project[0].

This commit patches the cc_wrapper of Bazel that gets installed on
Darwin to remove the last argument if it's an empty string. This is
not a probem on Linux.

[0]: https://github.com/bazelbuild/examples/tree/master/cpp-tutorial/stage3
2019-06-29 11:07:21 -07:00
Guillaume Bouchard
d086d45952 Fix source url for java tools on darwin 2019-06-24 11:41:43 +02:00
Guillaume Bouchard
27d4ce7ce0 bazel: Full switch to python3 2019-06-22 21:46:50 +02:00
Guillaume Bouchard
7fed6eabcf bazel: restore installCheckPhase
All the dependencies of this phase are prefetched and provided to the
bazel environment using --override_repository.
2019-06-22 21:46:50 +02:00
Guillaume Bouchard
ba327a54b6 bazel: 0.26.1 -> 0.27.0
- Fixs for newly introduced bin/bash hardcoded reference
- Bazel now references `remote_java_tools_xxx` which contains prebuilt
  binaries. We prefetch them, fix them, and force bazel to use the
  fixed repository.

It also closes #63096
2019-06-22 21:46:50 +02:00
Profpatsch
8ce4463d4a bazel: add update script to update srcDeps from WORKSPACE file 2019-06-18 17:47:01 +02:00
volth
f3282c8d1e treewide: remove unused variables (#63177)
* treewide: remove unused variables

* making ofborg happy
2019-06-16 19:59:05 +00:00
Wael Nasreddine
bad7bc44db bazel: fix nix-hacks.patch with the latest version of Bazel (#63052)
* bazel: add a failing test for nix-hacks

* fix the patch
2019-06-13 16:12:37 +02:00
Wael M. Nasreddine
f41667a774 bazel: 0.26.0 -> 0.26.1 2019-06-12 18:35:51 +02:00
Profpatsch
5d238e45de bazel: run the tests on all supported platforms 2019-06-12 14:09:42 +02:00
Profpatsch
629c050b5d bazel.tests: prebuild the bazel self-extraction to speed up test
Factor out the common parts of tests & cache the bazel
self-extraction (ugh) to a common store path.
2019-06-12 14:09:42 +02:00
Profpatsch
44f97b56d9 bazel: move the python test to py_binary
`py_test` tries to download unnecessary dependencies at runtime. We
can just as well run it to check the assertion.

Upstream issue: https://github.com/bazelbuild/bazel/issues/8575
2019-06-12 14:09:42 +02:00
Greg Roodt
dd2a0f6c4a bazel: 0.24.0 -> 0.26.0 2019-06-12 14:09:42 +02:00
Matthew Bauer
81a9b46ee8 bazel: use llvm6 on darwin
https://hydra.nixos.org/build/92942635
2019-05-07 19:43:46 -04:00
Daiderd Jordan
2e2ab461b7
Merge pull request #58147 from groodt/greg/bazel-0.23.2
bazel: 0.22.0 -> 0.24.0
2019-04-02 08:38:39 +02:00
Greg Roodt
d019fd8c8a bazel: 0.22.0 -> 0.24.0 2019-03-31 13:46:53 +11:00
Silvan Mosberger
555734eded bazel: Fix PATH escaping 2019-03-29 20:31:04 +01:00
Uri Baghin
130d987ab1 bazel-remote: init at 2019-01-12 2019-03-11 11:10:59 +01:00
Aaron Bull Schaefer
1b3b781d60 bazel-buildtools: unstable -> 0.22.0 2019-03-07 20:37:23 -08:00
Jörg Thalheim
dadc7eb329
treewide: use runtimeShell instead of stdenv.shell whenever possible
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
2019-02-26 14:10:49 +00:00
Carlos Morera de la Chica
9c406336f1 bazel: fix bash completion 2019-02-18 11:34:35 +01:00
Uri Baghin
2b2854e522 bazel-deps: 2018-11-01 -> 2019-02-01 2019-02-01 17:30:36 +11:00
Félix Baylac-Jacqué
a5aca72f93 bazel: 0.21.0 -> 0.22.0 2019-01-30 14:57:32 +01:00
Philip Patsch
5c6892e1a2 bazel: fix java toolchain regression
By changing the default toolchain to JDK8, we broke the default Java
toolchain, which assumes JDK9.

Instead, set `host_java_toolchain` manually for our build of bazel,
and set `java_toolchain` to run the java tests with the build JDK as
well.

Fixes https://github.com/NixOS/nixpkgs/issues/54289
2019-01-29 14:03:54 +01:00
Robin Palotai
566539ff55 Add test and docs. 2019-01-26 22:22:34 +01:00