Teach Linux to use local engine#31631
Conversation
stuartmorgan-g
left a comment
There was a problem hiding this comment.
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') |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
I've moved the copy the logic to the flutter tool, per my understanding of what the Makefile is doing...
|
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. |
…utter into land_desktop_asset_sync
|
|
||
| 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')); |
There was a problem hiding this comment.
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)); |
There was a problem hiding this comment.
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.
stuartmorgan-g
left a comment
There was a problem hiding this comment.
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.
|
Updated |
b0ff141 to
8c08fd1
Compare
stuartmorgan-g
left a comment
There was a problem hiding this comment.
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).
|
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 🤷♂️ |
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.
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? |
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 \ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 \ |
There was a problem hiding this comment.
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('/')) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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'; |
| if (flutterEngine != null) '--local-engine-src-path=$flutterEngine', | ||
| if (localEngine != null) '--local-engine=$localEngine', | ||
| ], | ||
| runInShell: true, |
There was a problem hiding this comment.
These shouldn't be runInShell
…utter into land_desktop_asset_sync
Description
Copy the linux artifacts!
Related Issues
#31367