- 27 Mar, 2022 1 commit
-
-
Zachary Anderson authored
-
- 26 Mar, 2022 3 commits
-
-
Alex Li authored
-
Chris Yang authored
-
Anurag Roy authored
-
- 25 Mar, 2022 3 commits
-
-
Christopher Fujino authored
-
Jenn Magder authored
-
Ahmed Ashour authored
-
- 23 Mar, 2022 1 commit
-
-
Danny Tuppeny authored
* Don't terminate Dart process pids from VM Service These processes may be on another device, and in the case of attach the debugee should not be terminated anyway.
-
- 22 Mar, 2022 5 commits
-
-
Danny Tuppeny authored
-
Anurag Roy authored
-
Michael Goderbauer authored
-
Chris Bracken authored
Previously, https://github.com/flutter/flutter/pull/100271 enabled building universal macOS binaries by default, but included a bug causing the arm64 App.framework to be built such that the TEXT section containing the app instructions built by gen_snapshot incorrectly contained x86_64 instructions rather than arm64 instructions. When building macOS (and iOS) apps, Flutter builds them in three components: * The Runner application: built by Xcode * The bundled App.framework: built from assembly code generated by gen_snapshot from the application's Dart sources. * The bundled FlutterMacOS.framework: built as part of the engine build and packaged by copying the distributed binary framework from our artifacts cache. Building App.framework consists of the following steps: * For each architecture, invoke gen_snapshot to generate architecture-specific assembly code, which is then built to object code and linked into an architecture-specific App.framework. * Use the `lipo` tool to generate a universal binary that includes both x86_64 and arm64 architectures. Previously, we were building architecture specific App.framework binaries. However, for all architectures we were (mistakenly) invoking the general `gen_snapshot` tool (which emitted x64 instructions, and which is now deprecated) instead of the architecture-specific `gen_snapshot_x86` and `gen_snapshot_arm64` builds which emit instructions for the correct architecture. This change introduces a small refactoring, which is to split the `getNameForDarwinArch` function into two functions: * `getDartNameForDarwinArch`: the name for the specified architecture as used in the Dart SDK, for example as the suffix of `gen_snapshot`. * `getNameForDarwinArch`: the name for the specified architecture as used in Apple tools, for example as an argument to `lipo`. For consistency, and to match developer expectations on Darwin platforms, this is also the name used in Flutter's build outputs. Issue: https://github.com/flutter/flutter/issues/100348
-
Jesús S Guerrero authored
-
- 21 Mar, 2022 1 commit
-
-
gaaclarke authored
-
- 17 Mar, 2022 8 commits
-
-
Dan Field authored
Fixes #86590
-
Jesús S Guerrero authored
-
Danny Tuppeny authored
-
Christopher Fujino authored
-
Liam Appelbe authored
-
Christopher Fujino authored
-
Chris Bracken authored
This changes the default build architectures for Flutter macOS apps to x86_64 and arm64. Previously, we manually excluded arm64 builds via the EXCLUDE_ARCHS Xcode setting in Flutter's generated xcconfig file. This eliminates setting EXCLUDE_ARCHS during the build and updates the default architectures in the tool and in the macos_assemble.sh wrapper. Issue: https://github.com/flutter/flutter/issues/97681 Umbrella issue: https://github.com/flutter/flutter/issues/60113
-
Brian Quinlan authored
-
- 16 Mar, 2022 2 commits
- 15 Mar, 2022 1 commit
-
-
Lau Ching Jun authored
-
- 14 Mar, 2022 1 commit
-
-
Christopher Fujino authored
-
- 10 Mar, 2022 2 commits
-
-
nicolasvac authored
-
Ben Konyi authored
-
- 09 Mar, 2022 5 commits
-
-
Chris Yang authored
-
Jeff Ward authored
-
Lau Ching Jun authored
-
Jenn Magder authored
-
Tacca authored
-
- 08 Mar, 2022 3 commits
-
-
Felix authored
Fixes a typo mutidex to multidex in a console hint to the user.
-
Jenn Magder authored
-
Chris Bracken authored
This patch adds an additional check to ensure the target length of a string is within the supported maximum string length prior to calling WideCharToMultiByte/MultiByteToWideChar in the Windows runner template. This is to prevent resize() from failing if called with a count > std::string::max_size(). According to Win32 API docs (WideCharToMultiByte, MultiByteToWideChar) it's the caller responsibility to make sure the buffers are correctly allocated. Authored by: Tomasz Gucio <tgucio@gmail.com>
-
- 07 Mar, 2022 2 commits
-
-
Jesús S Guerrero authored
-
Anurag Roy authored
-
- 05 Mar, 2022 1 commit
-
-
Jenn Magder authored
-
- 04 Mar, 2022 1 commit
-
-
Jonah Williams authored
-