refactor: GN builds on linux #12957
refactor: GN builds on linux #12957
Conversation
brightray/BUILD.gn
Outdated
| ] | ||
| outputs = [ "$target_gen_dir/libnotify-copy/libnotify/{{source_file_part}}" ] | ||
| } | ||
| } |
There was a problem hiding this comment.
What is the goal of this -- why do we need a copy of libnotify's headers?
There was a problem hiding this comment.
chromium on linux uses a custom sysroot, and doesn't read any files out of /usr/include. That sysroot is built out of a predefined set of packages.
That predefined set does not include libnotify. I tried adding /usr/include to the include paths, but that caused a bunch of other issues with other headers that happened to be in /usr/include. This was the way I found to add only the system's libnotify headers to the include path.
Ultimately, I think the generate_library_loader tool is the best way to handle the libnotify dependency; it looks like the loader we have might initially have been generated that way by hand.
There was a problem hiding this comment.
I checked into generate_library_loader; it doesn't solve the sysroot issue.
The reason chromium uses a custom sysroot is so that they can be sure that the binaries they build will run on the oldest version of Debian they support. See the rationale here: https://chromium.googlesource.com/chromium/src/+/7e0f41ff93cb6bd3f3956ad6251f34230b921f09/build/linux/sysroot_scripts/install-sysroot.py#9
It wouldn't be unreasonable to add a gclient hook that would add the relevant libnotify headers to that sysroot.
Not perfect yet but it builds, runs & shows a WebContents.
Ignore the first commit, it's just #12949.