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).
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
When cross compiling to the same kernel / arch combination, it is safe
to use strip of libraries. This happens when cross-compiling musl
programs. dontStrip is now set in each gcc compiler instead of in
gcc/builder.sh.
Fixes#75476
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
Fixes up the usage of patches/postInstall. Also removes `stdenv.lib` and
other minor tweaks.
Based on feedback from Sandro and Mihai.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
d81e4d9f66 contained some minor fixes to the yosys derivation
that make it a little easier to read and maintain. Incorporate those.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
These plugins can be included in a closure, along with the `yosys`
derivation, and they will be automatically picked up for use. For
example, this allows you to include 'yosys-bluespec' in your
`buildInputs`, and then immediately run:
$ nix-shell -p yosys yosys-bluespec yosys-ghdl
$ yosys -m bluespec -p 'help read_bluespec'
$ yosys -m ghdl -p 'help ghdl'
These two plugins are a bit experimental, admittedly, but they are good,
clean examples of how to write and use the yosys plugin infrastructure,
and make it easy to test updates, etc.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
By default, when yosys looks for plugins with the `-m` flag or `plugin`
command, it always looks in `YOSYS_PREFIX/share/yosys/plugins` for a
`.so` file, and loads that.
By design, this is intended to be a single, global, mutable location
such as `/usr/share/yosys/...` on disk, and plugins are supposed to
install their `.so` files here after yosys is installed, and they all
coexist together. Obviously, this won't work for us, but users might
expect these plugins to still work. More importantly, they won't want to
add special cases to their build systems.
Instead, to allow Nix users to use yosys plugins with the same UX (e.g.
natively call `plugin bluespec` or `-m ghdl`), we add a patch to yosys
that allows it to search a new `NIX_YOSYS_PLUGIN_DIRS` search path
environment variable. In tandem, we add a setup hook that adds to this
search path if a package has a `$out/share/yosys/plugins` directory.
Thus, it's enough to just include `yosys`, and any package that has a
yosys plugin in `$out/share/yosys/plugins`, and you can load it with
`-m` or the `plugin` command.
We could use a style like the haskellPackages set, where the set of
packages are "encased" in a lambda, and we pass packages that are
compatible with that version of the compiler:
haskell.packages.ghc8102.ghcWithPackages (p: with p; [ ... ])
but, realistically, there will probably only ever be one version of
yosys and one set of compatible plugins, so this seems overdone.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This unreleased version of GHDL fixes a bunch of bugs. It also contains
a few internal API changes for synthesis support -- required by the GHDL
yosys plugin.
Ideally, we can just remove this when 0.38 comes out.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Some applications, like the Jetbrains IDEs, check for a suffix to
determine if a stable JDK is used.
This flag was already passed for older versions, but it got lost for
OpenJDK 14+.
This is used in https://github.com/tweag/gomod2nix to reconstruct a
vendor metadata file.
With the vendor checks we need a lot more metadata which isn't
relevant for building packages, especially since we've already locked
the dependency graph ahead of time
This has been ported from FreeBSD: https://reviews.freebsd.org/D24122
* fixed buildInputs and nativeBuildInputs for cross compilation
* don't use pkgconfig alias
* simplified patchPhase
* made the version variable overridable in preBuild
Instead of copying the whole dart derivation to bin/cache/dart-sdk
directory, just symlink it.
Also, make sure that the flutter is build from dart passed as a
parameter.
Before:
/nix/store/p3avfmvd0yrjpwwml7vvqbjin5vacx2k-flutter-stable-1.22.0 2084894968
After:
/nix/store/750k4z1yj5xsw7ymmwvn7cfjjzkaygzg-flutter-stable-1.22.0 1647047080
We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh @matthewbauer
Upstream NextPNR has moved to disable the GUI by default; it tends to
cause the most complications/bug reports and has various complexities
and failure modes (e.g. I've still had problems getting it working
efficiently on my Ice Lake laptop.)
Instead, disable GUI support by default, and add a new `nextpnrWithGui`
derivation that enables it. This cuts the closure size down by 40ish
percent (~800MB -> ~500MB) and makes it a neglibile amount faster.
It also fixes two bugs:
1) We were using the old `ICEBOX_ROOT` parameter for ice40 support,
now known as `ICESTORM_ICE40_PREFIX`, and
2) the CMake option `SERIALIZE_CHIPDB` was renamed to `..._CHIPDBS`
(with an 'S' suffix) which should speed up the build at the cost
of RAM usage
Signed-off-by: Austin Seipp <aseipp@pobox.com>
NixOS 20.0.9's default NVIDIA video driver version is 455.38, which supports CUDA 11.1.1.
**Things to note:**
- [ ] Users with nvtop installed may need to upgrade their nvtop installation due to caching behavior
