AudioUnit is required on macOS.
See ./configuration output line:
checking for COREAUDIO_LIBS (-framework CoreAudio -framework AudioUnit)... ld: framework not found AudioUnit
From the project's homepage [1]:
Ozone — The J-Link Debugger and Performance Analyzer
Ozone is a cross-platform debugger and performance analyzer for J-Link
and J-Trace.
- Stand-alone graphical debugger
- Debug output of any tool chain and IDE 1
- C/C++ source level debugging and assembly instruction debugging
- Debug information windows for any purpose: disassembly, memory,
globals and locals, (live) watches, CPU and peripheral registers
- Source editor to fix bugs immediately
- High-speed programming of the application into the target
- Direct use of J-Link built-in features (Unlimited Flash
Breakpoints, Flash Download, Real Time Terminal, Instruction Trace)
- Scriptable project files to set up everything automatically
- New project wizard to ease the basic configuration of new projects
1 Ozone has been tested with the output of the following compilers:
GCC, Clang, ARM, IAR. Output of other compilers may be supported but is
not guaranteed to be.
[1]: https://www.segger.com/products/development-tools/ozone-j-link-debugger
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
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
Important changes:
- The 'isync' compatibility wrapper was removed.
- The Master/Slave configuration keywords where deprecated and should be
replaced with Far/Near. All users should update their configuration
file accordingly. It's a trivial change and the old Master/Slave
keywords will still work for now but result in the following message:
Notice: Master/Slave are deprecated; use Far/Near instead.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
The "kernel" argument to linuxPackagesFor was taking precedence over the
"self.kernel" attribute brought into scope by the "with self;" statement. This
prevented the makeExtensible machinery from working correctly when "kernel"
was overridden.
* 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)
Some packages have specific autotools requirements that don't apply to
any other packages. We want to be able to use autoreconfHook for
these packages with the required autotools versions, but we don't want
to have to makeSetupHook for each one, or have a top-level attribute
for every combination.
So, use callPackage around the makeSetupHook call so that the
autotools used by autoreconfHook can be overridden. This way, a
custom autoreconfHook can be passed to a package like this:
autoreconfHook = with buildPackages;
autoreconfHook.override { automake = automake115x; };
And we can simplify the definitions of our existing autoreconfHook264
and autoreconfHook269 attributes.
The attribute was initially renamed in ef403beb this way due to
incompatibilities between versions 0.4.x and 0.5.x back in 2010.
Additionally it hinders intuitive discovery of the package, because the
versioned package name is nothing a user would guess.
As we are moving to 0.6.0 this makes little sense anymore.