Needs to do a build in 2-pass now since Google stopped shipping all
dependencies needed to build Flutter. This may be an oversight from them
since they used to ship everything, but this makes the whole build
process more robust.
The first step will download all dependencies from pub, and the
second step will build Flutter. Since we need to build repository
first, we also require a new depsSha256 parameter to be passed, that
represents the SHA256 of the resulting derivation of all Flutter
dependencies downloaded from https://pub.dev.
This commit also makes some changes in mkFlutter, allowing the
user to pass src instead of passing version/channel/filename, allowing
for more flexibility (i.e: building from a local fork of Flutter).
Related issue #108606.
Nowadays we have multiple outdated versions of Flutter in nixpkgs.
Instead, let's focus in having in having stable versions of Flutter
working.
Users needing to use beta or dev versions of Flutter can use mkFlutter
function, that still exists.
This was causing release-cross to fail hydra eval, so it hasn't been
building for the last few days. So note that although ghcjs still
does not build, this fixes eval so the jobset can proceed.
Verified with `hydra-eval-jobs pkgs/top-level/release-cross.nix -I nixpkgs=.`
Matches generic clang compilers, and fixes isClang inspection, which
0710308402 depends on for the
`--gcc-toolchain` flag to be set up properly.
Fixes rocm-comgr
Previously zz wouldn't be able to compile anything using standard
modules like mem or log out of the box.
To fix this we copy the modules directory included in the source to
$out/share/zz/modules and add an entry to ZZ_MODULE_PATHS in the wrapper
around zz.
We also remove a search path entry which used to reference /build
because it used CARGO_MANIFEST_DIR at build time. The default search
path now includes:
* /nix/store/modules
* $out/share/zz/modules
* $(pwd)/modules
Patching out /nix/store/modules would be kind of cumbersome as it is a
multi-line entry, but it probably does no harm and fine to leave in.
An issue arising by this PR might be that the added search path entry
may take priority over an user specified location even though we use
--suffix. This is because zz internally uses a HashSet which has no
guaranteed iteration order. This may lead to unexpected behavior for
users wo previously provided custom versions of the standard modules via
ZZ_MODULE_PATHS. However, this is an issue in upstream issue as well
where ZZ_MODULE_PATHS may or may not take priority over the compiled in
search path, so this issue should probably be resolved upstream (I'll
file a report or PR).
