A directory full of *.nupkg files is a valid nuget source. We do not need mono
and the Nuget command line tool to create this structure. This has two
advantages:
- Nuget is currently broken due to a kernel bug affecting mono (#229476).
Replacing the mkNugetSource implementation allows affected users on 6.1+
kernels compile .NET core packages again.
- It removes mono from the build closure of .NET core packages. .NET core
builds should not depend on .NET framework tools like mono.
There is no equivalent of the `nuget init` command in .NET core. The closest
command is `dotnet nuget push`, which just copies the *.nupkg files around
anyway, just like this PR does with `cp`.
`nuget init` used to extract the *.nuspec files from the nupkgs, this new
implementation doesn't. .NET core doesn't care, but it makes the license
extraction more difficult. What was previously done with find/grep/xml2 is now
a python script (extract-licenses-from-nupkgs.py).
Members of the [package] table in Cargo.toml can be either subtables, or
values like strings and bools. Python is happy to check for membership
of "workspace" in a string, since Python strings are iterables, but if
the value is a bool, Python will throw an exception.
LLD supports Windows-style linker arguments, but these previously
triggered purity check false positives, because it saw that they
started with a '/' and assumed they were paths.
This tweaks the path detection to allow through certain values that
could be paths, but are much more likely to be LINK.EXE-style flags.
The risk of false negatives here is low — the only things we'd now
fail to catch would be attempts to link with libraries in the root
directory, which doesn't happen in practice.
We also teach the wrapper how to apply its purity checks to library
paths specified with the /LIBPATH: option.
Tested that paths we expect to be rejected (like /lib/libfoo.so) still
are.
v1 lockfiles can contain multiple references to the same version of a
package, and these references can contain different `integrity` values,
such as one having SHA-1 and SHA-512, while another just has SHA-512.
Given that HashMap iteration order isn't defined, this causes
reproducibility issues, as a different integrity value could be chosen
each time.
Thanks to @lilyinstarlight for discovering this issue originally, as well
as the idea for the sorting-based implementation.
According to <https://gcc.gnu.org/legacy-ml/gcc-patches/2015-08/msg00836.html>,
all code is position-independent on Windows. Some compilers
apparently warn for -fPIC on Windows, and clang errors:
> clang-15: error: unsupported option '-fPIC' for target 'x86_64-pc-windows-msvc'
I'm guessing the check was hostPlatform instead of targetPlatform by mistake.
In f8ee061247, the fallback installPhase
if fFetchAttrs.installPhase is not provided, became dynamically computed.
Due to operator precedence this had the side effect of appending to
fFetchAttrs.installPhase if it is provided, breaking custom
installPhases altogether.
rustc supports way more platforms than Linux and Darwin. We might not
be able to build it for every platform at the moment, but that's what
meta.broken is for.
There are other platforms that rustc can produce binaries for, but
can't run on itself, so those are listed in the defaults for
buildRustPackage.
If multiple files with the same build id were found, we silently randomly
overwrote one with the other.
Change the order to make the output deterministic, and emit a
warning when overwriting.
* buildGoModule: don't inherit postBuild hook when building go-modules
This is a slight revert of 5ce647b8bf
(#212800).
Inheriting these hooks in the `.go-modules` derivation can be confusing:
One doesn't expect them to run when generating the fixed output modules
derivation, but only on the main derivation. A `postBuild` hook that
adds some files to $out will cause a very hard to debug issue[1].
This commit adds support for a dedicated `modPostBuild` hook that will
be used only by the derivation building `.go-modules`. Additionally,
`go.section.md` now explains these attributes behavior better.
[1]:
https://discourse.nixos.org/t/cant-update-a-go-package-getting-go-inconsistent-vendoring/27063/6
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Some Flutter packages require additional attribute values to be added to buildFlutterApplication, to add things like libraries and environment variables.
To prevent duplication in applications that use the packages, a repository of package overrides is kept. buildFlutterApplication will look for package overrides for each dependency, and apply them by calling overrideAttrs on itself.
This allows thing like `flutterBuildFlags` and `runtimeDependencies` to be overridden with `overrideAttrs`.
Attributes that affect dependency retrieval cannot be overridden.
This uses `dart pub deps` (https://dart.dev/tools/pub/cmd/pub-deps) to retrieve information about project dependencies.
It requires a fetch-dart-deps derivation as input.
This wraps Flutter programs with an appropriate LD_LIBRARY_PATH.
For some reason, the RUNPATH of the executable is not used to load dynamic libraries in dart:ffi with DynamicLibrary.open().
This could alternatively be fixed with patchelf --add-needed, but this would cause all the libraries to be opened immediately,
which is not what application authors expect.
The name of the runtimeDependencies argument was chosen to match autoPatchelfHook, which has a similar feature.
This reduces the size of the executable.
It works well with Nix - if the user includes the version in their bug report, the exact debugging symbols required can easily be found.
88275ca6d6 inadvertently stopped the pubspec.lock from changing, as it copied the file before running pub get.
pub get can modify the pubspec.lock to update it to newer formats (for example by adding hashes and updating URLs, see an example diff below). We do not need the modifications at any later stage, so we can preserve the original file.
boolean_selector:
dependency: transitive
description:
name: boolean_selector
+ sha256: "6cfb5af12253eaf2b368f07bacc5a80d1301a071c73360d746b7f2e32d762c66"
+ url: "https://pub.dev"
- url: "https://pub.dartlang.org"
source: hosted
+ version: "2.1.1"
- version: "2.1.0"
Pub does not perform any Git operations on the cached package directly, instead cloning it through a mirror.
The .git directories are not needed, and are a source of non-determinism.
Co-authored-by: FlafyDev <flafyarazi@gmail.com>
The dependency fixed-output derivation now uses the recursive hash mode to avoid tarballing and copying all the files.
https://github.com/NixOS/nix/issues/6660 was ran into during the development of this change. Input references were found in the Git package cache before nukeReferences was used.
It turns out that the mirrors in the Git package cache do not actually need to be preserved, as the SDK does not use them during the build process. They are therefore deleted in the dependency derivation and re-created as blank repositories in the main derivation.
A description of the Git package cache layout can be found here: c890afa1d6/lib/src/source/git.dart (L339)
Files and directories such as .dart_tool, .flutter-plugins, .packages and .pub-cache/hosted/*/.cache will be happily regenerated by the SDK in an offline environment.
The patches being made to these files and directories to remove non-determinism were flawed: They did not handle cases where files only appeared in one run, or cases where tooling versions had an effect on the output.
While this may be beneficial for packages that ship native binaries, this causes issues due to Flutter packages that have inappropriately uploaded build artifacts (such as those from example subprojects) to pub.dev.
Without this PR, unlike `RUST_LIB_BACKTRACE=1 cargo run` you won't
get line numbers in backtraces from binaries built with:
```
nix build -f Cargo.nix --arg release false
```
This PR fixes that.
In https://github.com/NixOS/nixpkgs/pull/209870 I tried to unify the
treatment of clang and gcc in cc-wrapper as much as possible.
However it appears that I went too far.
Clang requires -isystem flags in order to be able to find gcc's
libstdc++. Gcc does not need these flags. If they are added,
gfortran will get confused:
https://github.com/NixOS/nixpkgs/pull/209870#issuecomment-1500550903
This commit deunifies the chunk of code that adds the -isystem
flags, and explains why this chunk applies only to clang.
When I authored the nix file in
335a9083b0,
`makeSetupHook` didn't know about `passthru` or `meta`.
So I foisted these attributes on the
derivation with `.overrideAttrs`.
Commits ba895a7da8 and
48034046bf enabled
`makeSetupHook` to receive these attributes directly.
It seems advisable to use that instead of `.overrideAttrs`.
The build.rs script shipped with evdev-sys attempts to detect cross
compilation and uses a completely different codepath which does a
`git fetch` inside the build script. This doesn't work in nixpkgs.
This PR adds a `touch libevdev/.git` to trick the `build.rs` into
thinking that it is not necessary to do a `git fetch`.
Thanks to @figsoda for finding this more-elegant solution to the
problem (my original solution needed to patch `build.rs`):
https://github.com/NixOS/nixpkgs/pull/224893#pullrequestreview-1373809617
Tested on:
- [x] `aarch64-linux` (cross from `x86_64-linux`)
Git dependencies with install scripts are built isolated from the main
package, so their development dependencies are required.
To take advantage of this, #206477 is needed.
This splits prefetch-npm-deps into multiple files, as well as making a
few small changes along the way, such as going from a `HashMap` to a `Vec`
as the container for packages, to deduplicate them more efficently.
