Support 'flutter build' for desktop targets #30706
Comments
stuartmorgan-g
added
tool
|
Any support we can provide for this in the short term is very valuable for the workflow of people trying out early stages of the desktop support, since if it's possible to do one-time setup of a pluggable build step, then once the project is set up manually, the edit-build-run/debug cycle in IDEs that support Flutter will work for free. |
|
For macOS, things I'm aware of remaining within the scope of this bug:
|
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. Related to flutter#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. Part of flutter#30706
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
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 flutter#30706
|
This is essential, I can't rely on a code that can't be built and delivered. |
|
I think given the plans around |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
Tracks being able to
flutter buildfor macOS, Windows, and Linux.In the long term this would use the templates created by
create(see #30703, #30704, and #30705), but shorter term—and also longer-term to support use cases other thanflutter create, such as Add-to-App—it would be good to support pluggable build steps.The text was updated successfully, but these errors were encountered: