Fixing `bazel_4` after #234710
Error example
https://hydra.nixos.org/build/241174862/nixlog/1
```
Execution platform: //:default_host_platform
third_party/zlib/gzwrite.c:89:20: error: call to undeclared function 'write'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
writ = write(state->fd, strm->next_in, put);
^
```
Similar to #269481 and #269297
Fixing `bazel_5` after #234710
Error example
https://hydra.nixos.org/build/241240612/nixlog/1
```
external/com_google_absl/absl/meta/type_traits.h:560:8: error: builtin __has_trivial_assign is deprecated; use __is_trivially_assignable instead [-Werror,-Wdeprecated-builtins]
(__has_trivial_assign(ExtentsRemoved) || !kIsCopyOrMoveAssignable) &&
```
Similar to #269297, and remaining `bazel_4` is WIP for another PR
bazel_6 https://hydra.nixos.org/build/241090720/nixlog/1
```
external/upb/upb/upb.c:228:25: error: defining a type within '__builtin_offsetof' is a Clang extension [-Werror,-Wgnu-offsetof-extensions]
n = UPB_ALIGN_DOWN(n, UPB_ALIGN_OF(upb_Arena));
^~~~~~~~~~~~~~~~~~~~~~~
```
bazel_6 https://hydra.nixos.org/build/241127779/nixlog/1
```
In file included from external/com_google_absl/absl/algorithm/container.h:55:
external/com_google_absl/absl/meta/type_traits.h:560:8: error: builtin __has_trivial_assign is deprecated; use __is_trivially_assignable instead [-Werror,-Wdeprecated-builtins]
(__has_trivial_assign(ExtentsRemoved) || !kIsCopyOrMoveAssignable) &&
^
```
Note: `bazel_5` and `bazel_4` require more work, for some reason extra
`-Wall` in combination with `-Werror` sneaks in and overrides `-Wno-`
settings, haven't managed yet to debug where exactly are the last
flags (last one wins) come from there.
ZHF: #265948
https://hydra.nixos.org/build/240805256/nixlog/1https://hydra.nixos.org/build/240805170/nixlog/2
Failure is a bit obscured but long story short, a script within
bazel gets custom nixpkgs shebang which in turn makes shell run
in POSIX-compatible mode. Bazel expects bash in non-POSIX mode
and osx-specific script starts to fail due to `set -e` and subshell
interaction differences in those modes (sub-shells and functions
suddently start inheriting `set -e` and fail to produce desired
output). More debug info is available in #267670
Shell scripts aren't guaranteed to work as interpreters in shebang.
In particular thin shell wrappers aren't shebang-ready on MacOS.
It may work sometimes depending on what exactly would try to execute
a script with such shebang, but generally it's not guaranteed to work.
See #124556
Bash wrapper was introduced in #266847 and so far seems like the
issue only affects darwin builds: hydra failure is in osx-specific
script, also shebang issue is usually darwin-specific.
Let's wrap it as a native binary to make it shebang-compatible.
The wrapper is only currently added to `bazel_6` so no need for
changes in other versions.
ZHF: #265948
The maven `dependency:go-offline` plugin has various issues
(see https://issues.apache.org/jira/browse/MDEP-204 and other
issues in that tracker), which the dedicated plugin from
https://github.com/qaware/go-offline-maven-plugin largely
fixes. I have confirmed that for an application I'm packaging
outside of nixpkgs, dependency-track, this indeed makes the
build work while it didn't with `dependency:go-offline`.
The offline mode is only used in one place in nixpkgs, for
lemminx. That build still succeeds and the program starts, though
I haven't tested further.
The tests started to fail after the repo-wide python 3.10 -> 3.11 update.
This is caused by Bazel's py_binary rule setting the [`PYTHONSAFEPATH`][1]
environment variable, which only has an effect for Python >= 3.11.
Setting this variable avoids prepending the current working directory and the
script's directory. The current test code relied on this behavior and thus
failed with:
```
Traceback (most recent call last):
File "/build/.cache/bazel/_bazel_build/8bcfff1c77854f2a2b07d1413b0fc106/execroot/our_workspace/bazel-out/k8-fastbuild/bin/python/bin.runfiles/our_workspace/python/bin.py", line 6, in <module>
from lib import foo
ModuleNotFoundError: No module named 'lib'
```
See also [bazelbuild/bazel#7091][2]
[1]: https://docs.python.org/3.11/using/cmdline.html#envvar-PYTHONSAFEPATH
[2]: https://github.com/bazelbuild/bazel/issues/7091
Projects building with meson are currently installTargets. Map these
to install tags, which are roughly equivalent. This allows projects to
selectively install components.
Meson now comes with its own set of commands for building, testing,
installing etc., that by default wrap around Ninja. The reason to
prefer using the Meson commands is that they take additional
options (e.g. setting custom timeouts for tests — my motivation for
this change).
Here, I've modified the Meson setup hook so that Meson's test and
install commands will be used instead of Ninja's when Meson's
configurePhase is used. This restriction is to avoid starting to run
Meson directly when dealing with custom build systems that wrap around
Meson, like QEMU's. We don't use meson's compile command, as it just
runs ninja, and that's handled fine by the existing Ninja setup hook.
Naturally the Meson commands don't support entirely the same set of
options that the Ninja ones did, but I checked through Nixpkgs to find
any packages using Meson that used any options that wouldn't be picked
up by this new system. I only found one, and it was just setting
checkTarget = "test", which is the default value for Ninja and has no
Meson equivalent (because we directly tell Meson to run the tests
rather than going through a generic job system like Ninja).
Link: https://github.com/NixOS/nixpkgs/issues/113829
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
When specifying the `builder` attribute in `stdenv.mkDerivation`, this
will be effectively transformed into
builtins.derivation {
builder = stdenv.shell;
args = [ "-e" builder ];
}
This also means that `default-builder.sh` is never sourced and as a
result it's not guaranteed that `$NIX_ATTRS_SH_FILE` is set to a correct
location[1].
Also, we need to source `.attrs.sh` to source `$stdenv`. So, the
following is done now:
* If `$NIX_ATTRS_SH_FILE` points to a correct location, then use it.
Directly using `.attrs.sh` is problematic for `nix-shell(1)` usage
(see previous commit for more context), so prefer the environment
variable if possible.
* Otherwise, if `.attrs.sh` exists, then use it. See [1] for when this
can happen.
* If neither applies, it can be assumed that `__structuredAttrs` is
turned off and thus nothing needs to be done.
[1] It's possible that it doesn't exist at all - in case of Nix 2.3 or
it can point to a wrong location on older Nix versions with a bug in
`__structuredAttrs`.
