Skip to content

Teach Linux to use local engine#31631

Merged
jonahwilliams merged 27 commits intoflutter:masterfrom
jonahwilliams:land_desktop_asset_sync
May 11, 2019
Merged

Teach Linux to use local engine#31631
jonahwilliams merged 27 commits intoflutter:masterfrom
jonahwilliams:land_desktop_asset_sync

Conversation

@jonahwilliams
Copy link
Contributor

@jonahwilliams jonahwilliams commented Apr 25, 2019

Description

Copy the linux artifacts!

Related Issues

#31367

Copy link
Contributor

@stuartmorgan-g stuartmorgan-g left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with landing this approach (modulo the comment below about the timestamp logic, which I'm not sure will ever actually be used as written), but it might be easier to just skip ahead to absorbing FDE's copy script into flutter_tool and having the copy done on this side, since that's the goal anyway.

// Otherwise we can use the engine stamp.
stampContents = Cache.instance.getStampFileFor('linux-sdk').readAsStringSync();
}
linuxProject.editableHostAppDirectory.childFile('.generated_engine_stamp')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per comments on the other PR, I'm not sure it's useful to add this logic until flutter_tool is also doing the copy. At that point, it'll be easy to read the file and do logic on it (the way the current FDE copy script does).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've moved the copy the logic to the flutter tool, per my understanding of what the Makefile is doing...

@jonahwilliams jonahwilliams added the tool Affects the "flutter" command-line tool. See also t: labels. label Apr 29, 2019
@jonahwilliams
Copy link
Contributor Author

Sorry for the delay on this. I got everything mostly working locally and then noticed buttons weren't working on linux, so I had to take a trip to revert-land.


final String buildFlag = buildInfo?.isDebug == true ? 'debug' : 'release';
final Directory cacheDirectory = fs.directory(artifacts.getEngineArtifactsPath(TargetPlatform.linux_x64));
final Directory buildDirectory = fs.directory(fs.path.join(getLinuxBuildDirectory(), 'cache', 'flutter_library'));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should take this opportunity to standardize how/where we're pushing files. On macOS we have a hybrid of what FDE happened to be doing (putting the framework in the the build output directly) and what iOS does (putting everything in a Flutter/ folder), which we'll have to fix as a breaking change since we didn't adjust it at the time (which was an oversight on my part).

Let's match the iOS (and I assume Android? I haven't dug into it) structure of having a single folder where we push files. For macOS we can make it Flutter to match iOS; here we should probably use flutter since the capital letter folder things is an Xcode-project-ism.

So we'd make editableHostAppDirectory be linux/flutter instead of linux, and put .generated_flutter_root (which should lose the . in this new structure, I think) and all these files in that folder, and not put anything in the build directory.

copyDirectorySync(cacheDirectory, buildDirectory);

// Copy the ICU data.
final File icuDestination = fs.file(fs.path.join(getLinuxBuildDirectory(), buildFlag, 'data', _kIcuDataName));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The copy targets not be directly in the build output directory. The data and lib directories are for the actual binary output location; the idea is that the makefile copies everything into those locations so that there's a directory that could be zipped up and moved until there's a real installer plan for Linux. But that's something that should be done by the Makefile on the app side (copying from cache/flutter_library/, or with the above change just flutter/ to the bundle target location), not the flutter_tool side.

Copy link
Contributor

@stuartmorgan-g stuartmorgan-g left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good; holding off on approving until the FDE patch is updated and reviewed since we'll need to land them at ~the same time since it's now a breaking change.

@jonahwilliams
Copy link
Contributor Author

Updated

@jonahwilliams jonahwilliams force-pushed the land_desktop_asset_sync branch from b0ff141 to 8c08fd1 Compare May 3, 2019 17:10
Copy link
Contributor

@stuartmorgan-g stuartmorgan-g left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, looks good structurally!

What's the reason for this new script to be a bash script instead of a dart script with a simple .sh that invokes it? We need exactly this logic for Windows too, and rewriting a .bat version rather than just making this Dart from the start seems like unnecessary extra work (especially since I thought we wanted to move away from having new scripts be something other than Dart anyway).

@jonahwilliams
Copy link
Contributor Author

I did spend some time investigating moving this to dart, I don't see any big wins yet. File copying constitutes such a big part of the process and yet is so much easier in bash 🤷‍♂️

@stuartmorgan-g
Copy link
Contributor

I did spend some time investigating moving this to dart, I don't see any big wins yet.

The big win is not having to then also write it again it batch and then maintaining two ~identical scripts in two different languages for the foreseeable future.

File copying constitutes such a big part of the process and yet is so much easier in bash 🤷‍♂

An earlier version of this patch did at least the folder copy (and I thought some of the other parts) in Dart, and that code was just a few lines. Is there extra complexity somewhere?

@stuartmorgan-g
Copy link
Contributor

and then maintaining

And keep in mind that we already know we are going to need to make non-trivial changes to the logic here, because re-copying the files on every build is unsustainable; at some point we really need to address the fact that this new build workflow is a significant regression from FDE's due to needlessly thrashing the timestamps of files that are part of the rebuild/relink analysis steps of the native builds. So there is going to be real maintenance cost going forward.

(And we already have a potential solution to that, in the form of re-using the logic from FDE's existing copy script--which is written in Dart.)

local_engine_flag="--local-engine=${LOCAL_ENGINE}"
fi

RunCommand "${FLUTTER_ROOT}/bin/flutter" --suppress-analytics \
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you feel about this level of breakdown between the tool API and the build script? It could be generalized to support linux, macos, and friends.

The alternative, would be to teach the makefile to invoke the commands separately as part of the build.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with the copy and the build build being lumped together like this; I haven't run into anything I can think of that would make it problematic, and it ensures that the engine flags stay matched.

local_engine_flag="--local-engine=${LOCAL_ENGINE}"
fi

RunCommand "${FLUTTER_ROOT}/bin/flutter" --suppress-analytics \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with the copy and the build build being lumped together like this; I haven't run into anything I can think of that would make it problematic, and it ensures that the engine flags stay matched.

for (final String filename in artifactFiles) {
final String sourcePath = fs.path.join(sourceDirectory, filename);
final String targetPath = fs.path.join(targetDirectory, filename);
if (filename.endsWith('/')) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember why I did this; we should probably just check the source type to see if it's a directory or not instead of relying on a marker in the filename.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

using isDirectorySync is returning false for some reason, I ended up leaving it as the name check

String cacheDirectory;
switch (targetPlatform) {
case 'linux-x64':
cacheDirectory = 'linux/flutter/cache';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove 'cache'

if (flutterEngine != null) '--local-engine-src-path=$flutterEngine',
if (localEngine != null) '--local-engine=$localEngine',
],
runInShell: true,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These shouldn't be runInShell

@jonahwilliams jonahwilliams merged commit 8b0243f into flutter:master May 11, 2019
@jonahwilliams jonahwilliams deleted the land_desktop_asset_sync branch May 11, 2019 07:08
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

tool Affects the "flutter" command-line tool. See also t: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants