flutter-unwrapped will now not come with engine artifacts in its cache directory(`$out/bin/cache`).
To specify a different cache directory, set FLUTTER_CACHE_DIR.
Flutter's wrapper now sets FLUTTER_CACHE_DIR to set engine artifacts.
The sh file `$out/bin/internal/shared.sh` runs when launching Flutter and calls `"$FLUTTER_ROOT/bin/cache/` instead of our environment variable `FLUTTER_CACHE_DIR`.
I decided not to patch it since the script doesn't require engine artifacts(which are the only thing not added by the unwrapped derivation), so it shouldn't fail, and patching it will just be harder to maintain.
Appending to search paths allows dependencies to be replaced at runtime.
This is useful, for example, to the Dart packaging mechanism, which supplies a wrapped version of Git that spoofs cached Git package revisions for Pub.
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.
Flutter application derivations can add dependencies and build flags, but it's not as easy during development.
As an alternative to nix-shell, a custom Flutter wrapper can be built with dependencies required by projects.
This feature builds on the existing build environment setup techniques required for Linux desktop support, so is fairly cheap to maintain.
This brings the following benefits:
- Artifacts missing in the SDK tarball (such as prebuilts for linux-aarch64) can be obtained
- Artifacts can be patched more granularly (e.g. libflutter_linux_gtk is patchelf-ed for GTK3, and the linux-aarch64 assets have a postPatch to add some missing files)
- Minimal Flutter packages can be generated (e.g. mkFlutterApp only needs prebuilts for desktop Linux, and developers that don't care for desktop Linux can exclude the artifacts and dependencies)
It also paves the way for including manually built engine facts.
Flutter 3.5.0 adds a check to make sure that the Flutter and Dart tool executables are inside the SDK directory.
This does not play nicely with the wrapping and linking techniques used to package it. It is also impossible for there to be an issue related to binary locations, as everything is set up properly in the derivation.
The internal artifacts should be used, as they have been patched to use Nix libraries.
Co-authored-by: FlafyDev <flafyarazi@gmail.com>
Co-authored-by: gilice <gilice@proton.me>
Co-authored-by: hacker1024 <hacker1024@users.sourceforge.net>
Now that Flutter artifacts are patched, there is no need for a FHS at runtime or any stage of the build process.
Those relying on it for the Android SDK should look at https://github.com/tadfisher/android-nixpkgs.
This allows SDK artifacts (including build tools and libraries) to use the right interpreter and library locations, abolishing the need for a FHS or post-build patches.
`autoPatchelf` has been used through `autoPatchelfHook`, instead of the `autoPatchelf` command on just the artifact directory, due to the latter method not patching interpreter paths (https://discourse.nixos.org/t/trying-to-use-autopatchelf/24003).
Co-authored-by: FlafyDev <flafyarazi@gmail.com>
Co-authored-by: gilice <gilice@proton.me>
Co-authored-by: hacker1024 <hacker1024@users.sourceforge.net>
The following principles are now in place:
- All wrappers will include SDK file symlinks. There is not much of a reason to not do so, and removing the option to omit it makes it easier to understand what each wrapper does.
- There is no longer a way to get the previous derivation from a wrapper. This could yield unexpected results based on the wrapping order. Instead, "sdk", "unwrapped", and "noFHS" passthru attributes are provided where appropriate.
checkInputs used to be added to nativeBuildInputs. Now we have
nativeCheckInputs to do that instead. Doing this treewide change allows
to keep hashes identical to before the introduction of
nativeCheckInputs.
