Introduce architecture subdirectory for Windows build (#129805, #116196)

[pbo-linaro]

To implement windows-arm64 support, it is needed to add architecture as a subdirectory (#129805).

In short, when performing a flutter windows build, we have:

• Before: build/windows/runner/Release/gallery.exe
• After: build/windows/x64/runner/Release/gallery.exe

This convention follows what flutter linux build does.

The old "runner" folder is automatically cleaned to prevent confusion for users not aware of this change, and who could continue to use outdated binaries accidentally.

We didn't introduce any change in ephemeral build folder. This might be required when introducing another architecture, but it won't be a breaking change, as those files are not used by end user.

Since we use a fresh cmake folder, we introduce FLUTTER_TARGET_PLATFORM in flutter cmake file (#116196). This will be needed when targeting another architecture than x64, and will avoid to have to clean existing cmake files. An automatic migration was implemented to automate this change in existing applications.

Finally, we set a specific architecture when calling cmake. This fixes existing build and tests on Windows on Arm, where cmake tries to compile native windows-arm64 binaries by default (which fails to link x64 libraries). In more, it will avoid need to clean existing cmake files when introducing another architecture.

Design doc: flutter.dev/go/windows-arm64

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[pbo-linaro]

@loic-sharma Here it is!
Your comments are welcome, and those from other flutter devs as well.

For now, I focused on a minimal change, with tests working (on x64 and arm64).
Probably I can update some documentation as well, don't hesitate to say.

[pbo-linaro]

Fixed error reported by flutter analyze.

[pbo-linaro]

Fixed license message.

[pbo-linaro]

@loic-sharma I'm not sure if the failure (windows plugin_test) means that there is something missing, or if the test script itself (located elsewhere?) should be updated to reflect new path to binary plugintest_test.exe.

If you could help on this, that would be nice :).

[andrewkolos]

@loic-sharma Would you be interested in reviewing this?

[loic-sharma]

Yup will do!

[loic-sharma]

Can we move this to the generated configs in _writeGeneratedFlutterConfig?

flutter/packages/flutter_tools/lib/src/cmake.dart

Lines 101 to 109 in b7acafa

	# Generated code do not commit.
	file(TO_CMAKE_PATH "$escapedFlutterRoot" FLUTTER_ROOT)
	file(TO_CMAKE_PATH "$escapedProjectDir" PROJECT_DIR)
	set(FLUTTER_VERSION "$version" PARENT_SCOPE)
	set(FLUTTER_VERSION_MAJOR ${version.major} PARENT_SCOPE)
	set(FLUTTER_VERSION_MINOR ${version.minor} PARENT_SCOPE)
	set(FLUTTER_VERSION_PATCH ${version.patch} PARENT_SCOPE)
	set(FLUTTER_VERSION_BUILD ${buildVersion ?? 0} PARENT_SCOPE)

[pbo-linaro]

Linux build adds it directly to the cmake command, and IMHO, it's more explicit that putting it in another function.
FLUTTER_VERSION_* stuff is the same for all architecture, thus it makes sense to factorize it in a single place.

What do you think?

[loic-sharma]

Hm I agree we should align with Linux. If we move FLUTTER_TARGET_PLATFORM to the generated CMake config file, we would need to also update Linux. That seems out-of-scope for this PR, and we can follow-up with this change later if needed.

That said, I'm curious as to why Linux chose this approach. The generated cmake config file makes it easier to use the CMake project without the Flutter tool. Regardless, I'll close this off!

[pbo-linaro]

Thanks for accepting this.

[christopherfujino]

What happens if someone directly invokes a build via cmake without providing -DFLUTTER_TARGET_PLATFORM?

[loic-sharma]

@loic-sharma I'm not sure if the failure (windows plugin_test) means that there is something missing, or if the test script itself (located elsewhere?) should be updated to reflect new path to binary plugintest_test.exe.

It looks like you'll need to update this:

flutter/dev/devicelab/lib/tasks/plugin_tests.dart

Lines 296 to 300 in 53082f6

	if (await exec(
	path.join(rootPath, 'build', 'windows', 'plugins', 'plugintest', 'Release', 'plugintest_test.exe'),
	<String>[],
	canFail: true,
	) != 0) {

You should be able to run this test locally using these instructions: https://github.com/flutter/flutter/tree/master/dev/devicelab#running-tests-locally

TLDR, this should work:

cd path/to/flutter
cd dev/devicelab
../../bin/cache/dart-sdk/bin/dart bin/test_runner.dart test -t plugin_test_windows

Let me know if you run into any problems!

[pbo-linaro]

First fixing failed test, before addressing other comments in review.

[pbo-linaro]

Pushed resolved changes.

[pbo-linaro]

Fixed analyze not happy with raw cmake strings 'if(...'.

[pbo-linaro]

Added change to hardcode TargetPlatform to getWindowsBuildDirectory.

[loic-sharma]

Ideally this should have the same logic as the clean command's deletion:

flutter/packages/flutter_tools/lib/src/commands/clean.dart

Lines 116 to 143 in d9cb50e

	void deleteFile(FileSystemEntity file) {
	// This will throw a FileSystemException if the directory is missing permissions.
	try {
	if (!file.existsSync()) {
	return;
	}
	} on FileSystemException catch (err) {
	globals.printError('Cannot clean ${file.path}.\n$err');
	return;
	}
	final Status deletionStatus = globals.logger.startProgress(
	'Deleting ${file.basename}...',
	);
	try {
	file.deleteSync(recursive: true);
	} on FileSystemException catch (error) {
	final String path = file.path;
	if (globals.platform.isWindows) {
	globals.printError('Failed to remove $path. '
	'A program may still be using a file in the directory or the directory itself. '
	'To find and stop such a program, see: '
	'https://superuser.com/questions/1333118/cant-delete-empty-folder-because-it-is-used');
	} else {
	globals.printError('Failed to remove $path: $error');
	}
	} finally {
	deletionStatus.stop();
	}

Namely:

1. Show a progress bar
2. If a file in the build directory is in use, show a helpful error message describing how to stop the program using the file

@christopherfujino How would you feel about moving CleanCommand.deleteFile to FileSystemUtils?

[christopherfujino]

Hmm, this seems to do a lot more than I would expect a generic method named deleteFile. I'm ok with moving htis to FileSystemUtils if we use a more descriptive method name, like recursivelyDeleteEntity({bool showProgress = false})

[pbo-linaro]

Thanks, I'll move it and use that method then.

[pbo-linaro]

After trying to move this, it creates several changes that are not so welcome on this PR. (tests moving, etc).
Would that be acceptable to first use the initial version, and then refactor this in a subsequent PR?

[pbo-linaro]

Pushed fix for latest comments (cmake file, nit). I left open the discussion about deleteFile method, that should be moved in another PR IMHO.

FYI, I'll be off next week, so there will be some delay before I can answer.