Instead of requiring a name_output.sh, expect a file called
.app_filename in the macos/Flutter directory containing just the name of
the application. The expectation is that the Xcode build will create
that file with a script.
This is not intended as a long-term solution, but it's a substantial
improvement over name_output.sh:
- name_output.sh required constructing the full build output path; this
made sense when it was coupled with build.sh, but now that the
decision for where build output goes lives in flutter_tool, that logic
should as well.
- Changing the name of the application required also updating
name_output.sh, which is error-prone. With .app_filename, it can be
created using $PRODUCT_NAME, which means that the usual way of setting
the application name will automatically update this flow as well.
Part of #30706
Allows Windows builds to use the same structure and script as Linux
builds now use, calling into tool_backend to manage copying resources to
the project directory and building the bundle.
Also switches from expecting name_update.bat to expecting flutter\exe_filename
to be written during the build, as with the recent changes to the macOS build, to
reduce the amount of boilerplate needed in a windows\ project directory.
This implements focus and hover handling for Material buttons. It inserts Focus widgets into the tree in order to allow buttons to be focusable via keyboard traversal (a.k.a. TAB traversal), and Listener widgets into the InkWell to allow the detection of hover states for widgets.
Addresses #11344, #1608, and #13264.
Eliminates the need for a build.bat in the Windows build workflow, adding
preliminary support for building using msbuild. The handling of
vcvars64.bat may be refined in the future, but this serves as a starting point.
Some parts of the appbundle build process were based on the logic for building
APK packages. However, these steps (copying to a directory shared by all
build variants, and calculating a SHA) are not necessary for an appbundle.
- Removes SYMROOT from the Generated.xcconfig. Having it causes current
versions of Xcode to switch the project's build output to "Legacy",
which causes anything not overridden to use a project-relative build
directory instead of a shared directory in DerivedData, breaking
anything with subprojects that it depends on.
This means that `flutter run` and builds from Xcode will use
completely different build directories, but that each should be
internally consistent.
- Moves the FlutterMacOS.framework to $SRCROOT/Flutter. This is
consistent with the approach we're moving to for all desktop
platforms, and avoids issues finding it now that SYMROOT doesn't match
for the two different build modes.
Fixes#32494
This is the correct metric to report for compilation time benchmarks rather
than RunTime. Rename the 'gen_snapshot' value to merely 'snapshot' for
backwards compatibility and overall simplicity.
This change simplifies Dart's benchmarking of Flutter by making it easier to
adopt --report-timings (made for Dart to use), which makes the benchmarks
much more robust.
