From a script, identify public and private headers

19 views
Skip to first unread message

Karl Wiberg

unread,
Sep 17, 2017, 4:25:35 PM9/17/17
to gn-...@chromium.org
Hi all,

I'm trying to establish a bit more control over what WebRTC headers we allow our users (e.g. Chromium) to #include. My prototype basically works by making all WebRTC targets visibility-restricted to what's below the WebRTC root dir by default (in Chromium, this is //third_party/webrtc/*), and then manually setting visibility to * in some BUILD.gn files and some individual targets. Seems to work great AFAICT.

Step two is to count the number of headers in various directories whose targets have had their visibility set to * (since if it can be measured, it'll be vastly easier to improve). It turned out to be easy to make a Python script that parses the json output of "gn desc *", and by looking at each target's visibility, public, and sources, it looks like I can get the data I want—except for one thing: public_deps. If a header is owned by a target that's not *-visible, the header can still be #included by the outside world if a *-visible target lists the first target in its public_deps. I figured my script could just traverse the tree of public_deps, but no luck; "gn desc" lists all of a target's dependencies under just "deps", regardless of whether they were in public_deps or plain deps.

Step two, alternative method: Make a .cc file that #includes every WebRTC header, put it in a target that has deps on every *-visible WebRTC target, and run "gn check" and see which #include lines it complains about. "gn check" doesn't support json output, which makes parsing said output icky, but it works. However, I can't get it to list more than one error at a time. I can work around this by making ~1500 separate targets that each has a .cc file that #includes just one of the WebRTC header files, and then test them with 1500 separate calls to "gn check", but we're now past the point where it starts to feel silly.

Does this make sense? Is there a way to make this work (sanely)? Either some variation of either of the methods I described, or some other way entirely? Or if not, is there a reasonable change I could make to gn that would make it possible? For example, adding an --all-errors flag to gn check doesn't sound like it ought to be complicated...

--
Karl Wiberg | Software Engineer | kwi...@google.com | +46 70 696 1024

Dirk Pranke

unread,
Sep 27, 2017, 3:49:58 PM9/27/17
to Karl Wiberg, gn-dev
On Sun, Sep 17, 2017 at 1:25 PM, Karl Wiberg <kwi...@webrtc.org> wrote:
Hi all,

I'm trying to establish a bit more control over what WebRTC headers we allow our users (e.g. Chromium) to #include. My prototype basically works by making all WebRTC targets visibility-restricted to what's below the WebRTC root dir by default (in Chromium, this is //third_party/webrtc/*), and then manually setting visibility to * in some BUILD.gn files and some individual targets. Seems to work great AFAICT.

Step two is to count the number of headers in various directories whose targets have had their visibility set to * (since if it can be measured, it'll be vastly easier to improve). It turned out to be easy to make a Python script that parses the json output of "gn desc *", and by looking at each target's visibility, public, and sources, it looks like I can get the data I want—except for one thing: public_deps. If a header is owned by a target that's not *-visible, the header can still be #included by the outside world if a *-visible target lists the first target in its public_deps. I figured my script could just traverse the tree of public_deps, but no luck; "gn desc" lists all of a target's dependencies under just "deps", regardless of whether they were in public_deps or plain deps.

I think we should probably just fix this so that you can tell which deps are which (i.e., change GN). Mind filing a bug for that?

-- Dirk

Karl Wiberg

unread,
Sep 28, 2017, 3:53:09 AM9/28/17
to Dirk Pranke, gn-dev
Bug filed. I hope I managed to set the right component etc.

Dirk Pranke

unread,
Sep 28, 2017, 12:09:17 PM9/28/17
to Karl Wiberg, gn-dev
Yup, looks good :).

-- Dirk
Reply all
Reply to author
Forward
0 new messages