[gn] use generated_files to encode entitlement information #34216
Conversation
XilaiZhang
changed the title
|
What happens with |
|
Yes more context: Ideally I could obtain the leaf node filename with something like |
build/archives/BUILD.gn
Outdated
| destination = "libtessellator$dll" | ||
| }, | ||
| ] | ||
| if (host_os == "mac" && full_target_platform_name == "darwin-x64") { |
There was a problem hiding this comment.
Do we need to sign arm64 artifacts?
There was a problem hiding this comment.
My reasoning is #34112 (comment). Maybe @christopherfujino could help decide if it is a better choice to have a tight constraint?
There was a problem hiding this comment.
we don't currently build arm artifacts; however, I don't think you should exclude arm here.
There was a problem hiding this comment.
Sounds good, I have relieved the constraints
Ah, I see. I'm still of the opinion that this will be easier to maintain/extend if the metadata is attached to the "leaf" targets. When adding the metadata to the leaf targets, it should be possible to reconstruct the outputs without the need for |
|
I am currently looking for a way to commit and push files out of the scope of The recently pushed up commits (which includes everything under src/flutter directory), along with changes made outside of src/flutter directory (src/build etc.) would work together to produce the desired output. Currently only files under src/flutter are pushed, and they themselves would fail the checks. |
|
I think you're looking for the buildroot repo here https://github.com/flutter/buildroot |
|
Exactly, Thank you! I pushed up flutter/buildroot#585 on the buildroot side. |
| }, | ||
| { | ||
| source = "$root_out_dir/libtessellator$dll" | ||
| destination = "libtessellator$dll" |
There was a problem hiding this comment.
Currently I found some file differences when comparing BUILD.gn and GCS artifact. For example, for darwin-x64/artifacts.zip,
- the BUILD.gn in cs.opensource suggests the zip file should not contain gen_snapshot, and contain 3 exectuables in total. (https://cs.opensource.google/flutter/engine/+/master:build/archives/BUILD.gn;l=58-69)
- the BUILD.gn in this file suggests that the zip file should not contain gen_snapshot, but contain flutter_tester_fractional_translation, with 4 executables in total (83fef4b)
- However, on the latest artifact downloaded from GCS, the zip file extracted contains gen_snapshot, and does not contain flutter_tester_fractional_translation. and has 4 executables in total (https://pantheon.corp.google.com/storage/browser/_details/flutter_infra_release/flutter/ea756c55f29a1f1143a17379c70422d5438ad891/darwin-x64/artifacts.zip;tab=live_object?authuser=0)
Which one should be the source of truth? Thank you!
|
looks like the failure are caused by, the change in flutter/buildroot#585 did not get propagated into engine. I tested locally with:
What would be the correct way to propagate changes on buildroot side into engine? Thank you! |
You need to manually roll the hash in this line https://github.com/flutter/engine/blob/main/DEPS#L114. I'd recommend that you do that in a separate PR. |
|
Thanks for the instructions! Pushed up #34297 |
5 participants
context: #34112
#34180
This pr is based on discussion with zra, that we should remove changes to zip.py, zip_bundle.gni and other templates. Instead, use generated_files.
For the leaf nodes, the closest i can get was to use get_target_outputs to take out names from source files. However, get_target_outputs only works for actions, template and such, and would not work for sources such as //flutter/impeller/compiler:impellerc. So in this PR we still use hard coded file names. I can update with more information tomorrow morning.