The `otool` binary is provided by the `cctools` package (and `binutils`)
on darwin, which is properly packaged and compiled from source.
This old standalone `otool` was simply a symlink to `/usr/bin/otool`,
which notably depended on the user having already installed the Command
Line Tools via XCode, and would fail dependent builds if they hadn't.
Stop using obsolete `otool` package, preferring `cctools` (which
includes otool), on darwin.
Remove autoconf & automake from reqs, as they were unused.
Fixes#12670
This change is not backward compatible, in the sense that this allow you to
override the packages which used to be overriden by the last stage of
stdenv. Note, this does not mean that these packages would be used by
stdenv.
This condition used to be implicit in the sense that the stdenvOverrides
uses pkgs_6, instead of pkgs_7 as its super set, and also that each stage of
the compiler is build again the bootstrap packages of the previous stage,
thus overriden by the stdenv.override function.
This patch change the behaviour or overridePackages:
- Before, overridePackages was based on top of the set of packages
overriden by `~/.nixpkgs/config.nix` file.
- After, overridePackages should when given a function f, behave almost¹
the same as-if the packageOverrides attribute of `~/.nixpkgs/config.nix`
file attribute was set to f, assuming that we ignore the extra `self`
argument.
¹ It is not yet exactly the same because we have many paths which are
re-entering nixpkgs while taking the default attributes, such as the
bootstrap phase of stdenv. Thus if the nixpkgs configuration overrides any
of the dependencies need for the bootstrap, then we might get different sha.
Extract stdenvDefault from the set of all packages. As this set of
attributes are inter-dependant, probably due to stdenvOverrides, we have to
keep them in a close set of inter-dependent options.
I guess I will have to investigate more ...
While evaluating the derivation of xbursttools:
the condition `pkgs.stdenv ? overrides` causes the evaluation of
`stdenvCross`. This evaluation comes too early during the execution, as
it prevents the resolution of names such as `pkgs.lib`, and
`stdenvAdapaters.makeStdenvCross`, which we want to take from `pkgs`
instead of `self` in following patches.
By swapping the conditions, we effectively make the resolution of `pkgs.lib`
and `stdenvAdapaters.makeStdenvCross` possible through the pkgs attribute.
Note, the aliases are now computed against the set of packages defined in
the set of all packages, and no longer apply to any overriden package.
I think this is better as this reduces the amount of surprizes.
This modification change the names bound to the `helperFunctions` attribute
set, to be bound to `self` which is constructed by merging the same
`helperFunctions` set with the set of all packages.
This patch works as expected because none of the helperFunction names is
aliased by the name of a package.
The `helperFunctions` and `stdenvAdapters` both use the `pkgs` attribute as
input, either to inherit some properties, either to use it as argument.
The `pkgs` binding used in both expressions of the `helperFunctions` and
`stdenvAdapters` is no longer the result of the `applyGlobalOverrides`
function, but the argument of the `pkgsFun` function.
The `pkgsFun` functions is called twice under `applyGlobalOverrides`, and in
both cases, the first argument of `pkgsFun` correspond to the result of
`applyGlobalOverrides`.
Thus, this modification will change the bindings, but the evaluation of
`<nixpkgs>`.
A third call the `pkgsFun` exists under `overridePackages` in the set of all
packages. Previously, the `helperFunctions` and `stdenvAdapaters` would use
the functions defined as part of the default `<nixpkgs>` set. With this
modification, the `helperFunctions` and the `stdenvAdapters` are now using
the fix-point of the newly evaluated package set.
This implies that this modification allow the user to use
`overridePackages`, which is already not recommended for performance
reasons, to override the inputs of the `helperFucntions` and
`stdenvAdapaters` too, where this was not possible before.
