1. 07 Feb, 2024 8 commits
  2. 06 Feb, 2024 1 commit
    • Daco Harkes's avatar
      Move native assets to `isolated/` directory (#142709) · a069e62e
      Daco Harkes authored
      Native assets in other build systems are not built with `package:native_assets_builder` invoking `build.dart` scripts. Instead all packages have their own blaze rules. Therefore we'd like to not depend on `package:native_assets_builder` from flutter tools in g3 at all.
      
      This PR aims to move the imports of `native_assets_builder` and `native_assets_cli` into the `isolated/` directory and into the files with a `main` function that are not used in with other build systems.
      
      In order to be able to remove all imports in files used by other build systems, two new interfaces are added `HotRunnerNativeAssetsBuilder` and `TestCompilerNativeAssetsBuilder`. New parameters are then piped all the way through from the entry points:
      
      * bin/fuchsia_tester.dart
      * lib/executable.dart
      
      The build_system/targets dir is already excluded in other build systems.
      
      So, after this PR only the two above files and build_system/targets import from `isolated/native_assets/` and only `isolated/native_assets/` import `package:native_assets_cli` and `package:native_assets_builder`.
      
      Context:
      
      * https://github.com/flutter/flutter/issues/142041
      a069e62e
  3. 05 Feb, 2024 1 commit
  4. 02 Feb, 2024 3 commits
    • Bartek Pacia's avatar
      Reland "Add support for Gradle Kotlin DSL (#140744)" (#142752) · 6facb969
      Bartek Pacia authored
      This PR attempts to:
      - reland #140744
      - reland #141541 (which is also in #142300 - I will close it once this PR is merged)
      6facb969
    • Lau Ching Jun's avatar
      Avoid depending on files from build_system/targets other than from top level... · ac7879e2
      Lau Ching Jun authored
      Avoid depending on files from build_system/targets other than from top level entrypoints in flutter_tools. (#142760)
      
      Add a new `BuildTargets` class that provides commonly used build targets. And avoid importing files from `build_system/targets` except from the top level entrypoints or from top level commands.
      
      Also move `scene_importer.dart` and `shader_compiler.dart` into `build_system/tools` because they are not `Target` classes, but wrapper for certain tools.
      
      With this change, we can ignore all files in `build_system/targets` internally and make PR #142709 easier to land internally. See cl/603434066 for the corresponding internal change.
      
      Related to:
      https://github.com/flutter/flutter/pull/142709
      https://github.com/flutter/flutter/issues/142041
      
      Also note that I have opted to add a new variable in `globals.dart` for `BuildTargets` in this PR, but I know that we are trying to get rid of globals. Several alternatives that I was considering:
      
      1. Add a new field in `BuildSystem` that returns a `BuildTargets` instance. Since `BuildSystem` is already in `globals`, we can access build targets using `globals.buildSystem.buildTargets` without adding a new global variable.
      2. Properly inject the `BuildTargetsImpl` instance from the top level `executable.dart` and top level commands.
      
      Let me know if you want me to do one of the above instead. Thanks!
      ac7879e2
    • Jackson Gardner's avatar
      Wasm/JS Dual Compile with the flutter tool (#141396) · ba626dc8
      Jackson Gardner authored
      This implements dual compile via the newly available flutter.js bootstrapping APIs for intelligent build fallback.
      * Users can now use the `FlutterLoader.load` API from flutter.js
      * Flutter tool injects build info into the `index.html` of the user so that the bootstrapper knows which build variants are available to bootstrap
      * The semantics of the `--wasm` flag for `flutter build web` have changed:
        - Instead of producing a separate `build/web_wasm` directory, the output goes to the `build/web` directory like a normal web build
        - Produces a dual build that contains two build variants: dart2wasm+skwasm and dart2js+CanvasKit. The dart2wasm+skwasm will only work on Chrome in a cross-origin isolated context, all other environments will fall back to dart2js+CanvasKit.
        - `--wasm` and `--web-renderer` are now mutually exclusive. Since there are multiple build variants with `--wasm`, the web renderer cannot be expressed via a single command-line flag. For now, we are hard coding what build variants are produced with the `--wasm` flag, but I plan on making this more customizable in the future.
      * Build targets now can optionally provide a "build key" which can uniquely identify any specific parameterization of that build target. This way, the build target can invalidate itself by changing its build key. This works a bit better than just stuffing everything into the environment defines because (a) it doesn't invalidate the entire build, just the targets which are affected and (b) settings for multiple build variants don't translate well to the flat map of environment defines.
      ba626dc8
  5. 01 Feb, 2024 3 commits
  6. 31 Jan, 2024 3 commits
  7. 29 Jan, 2024 2 commits
  8. 26 Jan, 2024 3 commits
  9. 25 Jan, 2024 1 commit
  10. 24 Jan, 2024 2 commits
  11. 23 Jan, 2024 2 commits
  12. 22 Jan, 2024 2 commits
  13. 19 Jan, 2024 2 commits
  14. 18 Jan, 2024 5 commits
  15. 17 Jan, 2024 2 commits