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.
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.
* add trailing commas on list/map/parameters
* add trailing commas on Invocation with nb of arg>1
* add commas for widget containing widgets
* add trailing commas if instantiation contains trailing comma
* revert bad change
* adding support for android app bundle.
* removing the debug statement.
* fixing formatting and code review changes.
* Revert "fixing formatting and code review changes."
This reverts commit 2041d459f3.
* Fixing code formatting issues.
* updating review comments fixing comments and spacing.
* changing and to & to rerun the CI and tests.
* updating the comment to re-run the test
updating the comment to re-run the test
* fixing the formatting.
* updating comments to re-trigger build
updating comments to re-trigger build
We decided that redefining the default for templates was premature. We're going to go back to having "module" in experimental land again, and we'll try again when we have the feature set fully baked.
This keeps the writing of the .metadata files, and writing the template type to them, because that was a good improvement, and there are still a bunch of added tests that improve our coverage.
This renames the "module" template to the "application" template, and makes "application" the default. The existing "app" template is now deprecated.
flutter create also now recognizes the type of project in an existing directory, and is able to recreate it without having the template type explicitly specified (although you can still do that). It does this now by first looking in the .metadata file for the new project_type field, and if it doesn't find that, then it looks at the directory structure. Also, the .metadata file is now overwritten even on an existing directory so that 1) the project_type can be added to legacy projects, and 2) the version of Flutter that updated the project last is updated.
I also cleaned up a bunch of things in create_test.dart, added many more tests, and added an example test to the test/ directory in the generated output of the application template.
Fixes#22530Fixes#22344
* Prototype
* Fix paths to Flutter library resources
* Invoke pod install as necessary for materialized modules
* Add devicelab test for module use on iOS
* Remove debug output
* Rebase, reame materialize editable
* Add devicelab test editable iOS host app
* Removed add2app test section
Xcode 10 introduces a new build system which includes stricter checks on
duplicate build outputs.
When plugins are in use, there are two competing build actions that copy
Flutter.framework into the build application Frameworks directory:
1. The Embed Frameworks build phase for the Runner project
2. The [CP] Embed Pods Frameworks build phase that pod install creates
in the project.
Item (1) is there to ensure the framework is copied into the built app
in the case where there are no plugins (and therefore no CocoaPods
integration in the Xcode project). Item (2) is there because Flutter's
podspec declares Flutter.framework as a vended_framework, and CocoaPods
automatically adds a copy step for each such vended_framework in the
transitive closure of CocoaPods dependencies.
As an immediate fix, we opt back into the build system used by Xcode 9
and earlier. Longer term, we need to update our templates and
flutter_tools to correctly handle this situation.
See: https://github.com/flutter/flutter/issues/20685
This caused issues for projects without an Xcode workspace. Almost all
Flutter projects in the wild will have a workspace, but this patch needs
to add a check to catch any that lack one.
This reverts commit 021f472efc.
Xcode 10 introduces a new build system which includes stricter checks on
duplicate build outputs.
When plugins are in use, there are two competing build actions that copy
Flutter.framework into the build application Frameworks directory:
1. The Embed Frameworks build phase for the Runner project
2. The [CP] Embed Pods Frameworks build phase that pod install creates
in the project.
Item (1) is there to ensure the framework is copied into the built app
in the case where there are no plugins (and therefore no CocoaPods
integration in the Xcode project). Item (2) is there because Flutter's
podspec declares Flutter.framework as a vended_framework, and CocoaPods
automatically adds a copy step for each such vended_framework in the
transitive closure of CocoaPods dependencies.
As an immediate fix, we opt back into the build system used by Xcode 9
and earlier. Longer term, we need to update our templates and
flutter_tools to correctly handle this situation.
See: https://github.com/flutter/flutter/issues/20685
