Fix localized resource loading in Mac local builds via packaging. [chromium/src : main]
Lambros Lambrou (Gerrit)
Lambros Lambrou voted![]( "Open in Gerrit")
| Auto-Submit | +1 |
| Commit-Queue | +1 |
Related details
- Yuwei Huang
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Yuwei Huang (Gerrit)
Yuwei Huang voted and added 1 comment![]( "Open in Gerrit")
Votes added by Yuwei Huang
| Code-Review | +1 |
1 comment
if (!is_official_build) {I guess this is fine, but is there any concern with also adding the dependency for the official build?
Related details
- Lambros Lambrou
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Lambros Lambrou (Gerrit)
Lambros Lambrou voted and added 1 comment![]( "Open in Gerrit")
Votes added by Lambros Lambrou
| Commit-Queue | +2 |
1 comment
if (!is_official_build) {I guess this is fine, but is there any concern with also adding the dependency for the official build?
If we add the dependency for the official build, it would add 2 redundant copies of `libremoting_core.dylib` to the installed package structure. In official packages, this dylib is inside the main app bundle, alongside the 2 child bundles (the native-messaging host bundles). The rpath of each native-messaging executable causes this dylib to be found.
The problem with local builds was: the outer dylib (found by rpath resolution) lived in `out/Default` which is not a valid path inside any bundle, breaking the C++ code that tries to load resources.
Local builds are fixed by adding extra copies of the dylib inside the 2 native-messaging bundles. The rpath resolution looks in multiple places, and finds these copies first, and now they live inside proper bundle paths, and resource loading works.
I understand it's not ideal to have dylib-resolution and packaging logic depend on `if (!is_official_build)`. A proper fix (making local builds follow the same logic as packaged builds) would be very involved. So, pragmatically, this is a simple packaging change that is intended just to fix local builds, without touching any C++ code (the C++ changes in this CL just revert the previous CL).
Related details
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Chromium LUCI CQ (Gerrit)
Chromium LUCI CQ submitted the change![]( "Open in Gerrit")
Change information
Fix localized resource loading in Mac local builds via packaging.
Previously, we attempted to fix resource loading in Mac component builds
by disabling/adjusting the framework bundle path override logic in C++
(using COMPONENT_BUILD and OFFICIAL_BUILD guards).
However, this was fragile and left local non-component release builds
broken because they also load `libremoting_core.dylib` from the build
directory (via rpath) rather than from inside the bundle, leading to
incorrect path resolution in C++.
This CL reverts the C++ workarounds in `resources_mac.cc` to the
original clean state. Instead, we fix the issue by correcting the
packaging of local builds in GN. We add a dependency on
`remoting_core_bundle_data` to both `remote_assistance_host` and
`remoting_native_messaging_host` targets, but only for local builds
(`!is_official_build`).
This ensures that in local builds, `libremoting_core.dylib` is copied
into the respective app bundles. At runtime, the C++ code will load the
dylib from the bundle, and the original path-stripping logic will
correctly resolve the bundle path. Official builds remain unaffected and
continue to share the single dylib in the parent bundle to save space.
TAG=agy CONV=aefa24cb-e84e-4b9a-ac3a-389b5876b45d
- M remoting/host/it2me/BUILD.gn
- M remoting/host/mac/BUILD.gn
- M remoting/host/resources_mac.cc
Code-Review: +1 by Yuwei Huang
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |