Using fetchurl like this means that, if you build the `flutter`
derivation first, you will get a file named "LICENSE" in your store with
the correct hash. `flutter37` will then build because this file is
already in your store, even though the LICENSE to which _it_ refers is
different. This is dangerous in this case - but an intentional design
decision in the way fetchurl works to allow artifacts which are the same
to be fetched from arbitrary sources, or even pre-populated into the
store.
To avoid this, explicitly tag the fetchurl with a name and the commit
hash we're fetching from. This means we _must_ fetch these separately
for each flutter version and avoids the problem of accidentally reusing
artifacts for a different build.
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.
