headless: Implement client API generation

headless: Implement client API generation

Implement a C++ client API which can be used to control and
inspect a tab in the headless browser. The API consists of
C++ bindings for the DevTools remote debugging protocol and
is automatically generated from the protocol definition.

Design doc: https://docs.google.com/document/d/1rlqcp8nk-ZQvldNJWdbaMbwfDbJoOXvahPCDoPGOwhQ/edit#

BUG=595353
Committed: https://crrev.com/564a123cb9c2786db2b382a7f519cfbc65ae5e2f
Cr-Commit-Position: refs/heads/master@{#388488}

[Sami, 2016-03-22 12:18:44]

Snapshot

[Sami, 2016-03-22 12:22:11]

Added some missing files

[Sami, 2016-03-22 12:32:59]

Parsing

[Sami, 2016-04-11 19:12:11]

Description was changed from

==========
headless: Client API prototyping

BUG=595353
==========

to

==========
headless: Implement client API generation

Implement a C++ client API which can be used to control and inspect a tab in the
headless browser. The API consists of C++ bindings for the DevTools remote
debugging protocol and is automatically generated from the protocol definition.

Design doc:
https://docs.google.com/document/d/1rlqcp8nk-ZQvldNJWdbaMbwfDbJoOXvahPCDoPGOw...

BUG=595353
==========

[Sami, 2016-04-11 19:12:28]

Description was changed from

==========
headless: Implement client API generation

Implement a C++ client API which can be used to control and inspect a tab in the
headless browser. The API consists of C++ bindings for the DevTools remote
debugging protocol and is automatically generated from the protocol definition.

Design doc:
https://docs.google.com/document/d/1rlqcp8nk-ZQvldNJWdbaMbwfDbJoOXvahPCDoPGOw...

BUG=595353
==========

to

==========
headless: Implement client API generation

Implement a C++ client API which can be used to control and
inspect a tab in the headless browser. The API consists of
C++ bindings for the DevTools remote debugging protocol and
is automatically generated from the protocol definition.

Design doc:
https://docs.google.com/document/d/1rlqcp8nk-ZQvldNJWdbaMbwfDbJoOXvahPCDoPGOw...

BUG=595353
==========

[Sami, 2016-04-11 19:25:21]

skyostil@chromium.org changed reviewers:
+ altimin@chromium.org

[Sami, 2016-04-11 19:26:48]

PTAL, and let me know if you want me to split this up after all. Note I left
some features like events and convenience aliases for commands as follow-ups.

Also, it might help to see some of the generated output:

https://drive.google.com/open?id=0ByyxMXB38gLDdmp4UGhzdThHQ1U

[pfeldman, 2016-04-12 00:27:32]

pfeldman@chromium.org changed reviewers:
+ dgozman@chromium.org

[altimin, 2016-04-14 12:54:12]

https://codereview.chromium.org/1805983002/diff/520001/headless/app/headless_...
File headless/app/headless_shell.cc (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/app/headless_...
headless/app/headless_shell.cc:74: return;
Unremoved debugging?

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
File headless/lib/browser/client_api_generator.py (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:1: # Copyright 2016 The Chromium
Authors. All rights reserved.
I believe that this python code deserves some test coverage.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:45: raise Exception('Output
directory must be specified')
ValueError?

Or, even better, consider using argparse (python 2.7 & 3+), which has
required=True option.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:53: input_file =
open(input_json_filename, 'r')
Can we please avoid opening files and doing complex work when importing a
module?

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:59: return name[:1].upper() +
name[1:]
str.title?

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:63: return ''.join(ToTitleCase(x)
or '-' for x in word.split('-'))
Do we need "or '-'" here?

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:119: """for property in
type['properties']:
If this is some kind of documentation, then I don't get it :)

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/h...
File headless/lib/browser/headless_devtools_client_impl.cc (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/h...
headless/lib/browser/headless_devtools_client_impl.cc:262: void
HeadlessDevToolsClientImpl::SendMessage(const char* method,
Looks like these three methods have a lot in common. Should they be refactored?

[dgozman, 2016-04-14 18:01:54]

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/d...
File headless/lib/browser/domain_cc.template (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/d...
headless/lib/browser/domain_cc.template:46: if
(callback.Equals(base::Callback<void(std::unique_ptr<{{method_name}}Result>)>()))
There is is_null() method on Callback.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/h...
File headless/lib/browser/headless_devtools_client_impl.cc (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/h...
headless/lib/browser/headless_devtools_client_impl.cc:277:
agent_host_->DispatchProtocolMessage(json_message);
This could synchronously call |DispatchProtocolMessage| and since
pending_messages_ does not contain this message yet, callback won't be called.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
File headless/lib/browser/type_conversions_h.template (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
headless/lib/browser/type_conversions_h.template:62:
std::unique_ptr<base::Value> ToValueImpl(const {{namespace}}::{{type.id}}&
value, T*) {
I see two absolutely identical instances of this in generated file:
std::unique_ptr<base::Value> ToValueImpl(const dom::CopyToResult& value, T*)

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
headless/lib/browser/type_conversions_h.template:62:
std::unique_ptr<base::Value> ToValueImpl(const {{namespace}}::{{type.id}}&
value, T*) {
Also, all these functions are similar. Perhaps, we can do a single template?
template <typename T, typename S>
std::unique_ptr<base::Value> ToValueImpl(const S& value, T*) {
  return value.Serialize();
}

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
File headless/lib/browser/types_h.template (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
headless/lib/browser/types_h.template:19: // ------------- Forward declarations
and typedefs.
In generated files I see a forward declaration for class CopyToResult, but not
actual definition.

[Sami, 2016-04-15 14:43:45]

Thanks for reviewing my massive patch!

https://codereview.chromium.org/1805983002/diff/520001/headless/app/headless_...
File headless/app/headless_shell.cc (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/app/headless_...
headless/app/headless_shell.cc:74: return;
On 2016/04/14 12:54:11, altimin wrote:
> Unremoved debugging?

Argh, yes. Cleaned up.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
File headless/lib/browser/client_api_generator.py (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:1: # Copyright 2016 The Chromium
Authors. All rights reserved.
On 2016/04/14 12:54:12, altimin wrote:
> I believe that this python code deserves some test coverage.

Indeed, made it so.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:45: raise Exception('Output
directory must be specified')
On 2016/04/14 12:54:12, altimin wrote:
> ValueError?
> 
> Or, even better, consider using argparse (python 2.7 & 3+), which has
> required=True option.

Good idea, replaced with argparse.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:53: input_file =
open(input_json_filename, 'r')
On 2016/04/14 12:54:11, altimin wrote:
> Can we please avoid opening files and doing complex work when importing a
> module?

Agreed & removed.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:59: return name[:1].upper() +
name[1:]
On 2016/04/14 12:54:11, altimin wrote:
> str.title?

str.title() turns 'fooBar' into 'Foobar' which doesn't quite work for us.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:63: return ''.join(ToTitleCase(x)
or '-' for x in word.split('-'))
On 2016/04/14 12:54:12, altimin wrote:
> Do we need "or '-'" here?

Hmm, not sure why it was there (it was there on the generator this one is based
on). Removed.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/c...
headless/lib/browser/client_api_generator.py:119: """for property in
type['properties']:
On 2016/04/14 12:54:12, altimin wrote:
> If this is some kind of documentation, then I don't get it :)

Sorry, another commented-out test. Removed.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/d...
File headless/lib/browser/domain_cc.template (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/d...
headless/lib/browser/domain_cc.template:46: if
(callback.Equals(base::Callback<void(std::unique_ptr<{{method_name}}Result>)>()))
On 2016/04/14 18:01:54, dgozman wrote:
> There is is_null() method on Callback.

Thanks, I looked but completely missed that.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/h...
File headless/lib/browser/headless_devtools_client_impl.cc (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/h...
headless/lib/browser/headless_devtools_client_impl.cc:262: void
HeadlessDevToolsClientImpl::SendMessage(const char* method,
On 2016/04/14 12:54:12, altimin wrote:
> Looks like these three methods have a lot in common. Should they be
refactored?

Refactored.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/h...
headless/lib/browser/headless_devtools_client_impl.cc:277:
agent_host_->DispatchProtocolMessage(json_message);
On 2016/04/14 18:01:54, dgozman wrote:
> This could synchronously call |DispatchProtocolMessage| and since
> pending_messages_ does not contain this message yet, callback won't be called.

Well spotted, thanks.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
File headless/lib/browser/type_conversions_h.template (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
headless/lib/browser/type_conversions_h.template:62:
std::unique_ptr<base::Value> ToValueImpl(const {{namespace}}::{{type.id}}&
value, T*) {
On 2016/04/14 18:01:54, dgozman wrote:
> Also, all these functions are similar. Perhaps, we can do a single template?
> template <typename T, typename S>
> std::unique_ptr<base::Value> ToValueImpl(const S& value, T*) {
>   return value.Serialize();
> }

That's actually what I initially tried to do here, but the problem is it fails
for things like ToValue<std::vector<...>>() since there's no
std::vector::Serialize(). I then tried some increasingly complicated template
gymnastics and in the end got something that worked, but clang warned that it
was *technically* against the spec which wasn't a good sign :)

I think the other alternative would be to have a virtual base class for all user
types so we can specialize ToValueImpl just for them, but I decided to go with
this approach instead since most of the overhead evaporates at build time.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
headless/lib/browser/type_conversions_h.template:62:
std::unique_ptr<base::Value> ToValueImpl(const {{namespace}}::{{type.id}}&
value, T*) {
On 2016/04/14 18:01:54, dgozman wrote:
> I see two absolutely identical instances of this in generated file:
> std::unique_ptr<base::Value> ToValueImpl(const dom::CopyToResult& value, T*)

Hmm, where? I can only find one.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
File headless/lib/browser/types_h.template (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
headless/lib/browser/types_h.template:19: // ------------- Forward declarations
and typedefs.
On 2016/04/14 18:01:54, dgozman wrote:
> In generated files I see a forward declaration for class CopyToResult, but not
> actual definition.

Do you mean here?

https://drive.google.com/corp/drive/u/1/folders/0ByyxMXB38gLDdmp4UGhzdThHQ1U

I just noticed that drive is a bit dumb: you have to scroll all the way to the
bottom to make sure the whole file is loaded. CopyToResult only shows up after
that :P

[dgozman, 2016-04-15 20:51:13]

Overall, this looks good. Sorry, didn't really look into every single line of
templates and tests, but generated files are fine.

I guess, we will follow up with hidden/experimental story?

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
File headless/lib/browser/type_conversions_h.template (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
headless/lib/browser/type_conversions_h.template:62:
std::unique_ptr<base::Value> ToValueImpl(const {{namespace}}::{{type.id}}&
value, T*) {
On 2016/04/15 14:43:44, Sami wrote:
> On 2016/04/14 18:01:54, dgozman wrote:
> > Also, all these functions are similar. Perhaps, we can do a single template?
> > template <typename T, typename S>
> > std::unique_ptr<base::Value> ToValueImpl(const S& value, T*) {
> >   return value.Serialize();
> > }
> 
> That's actually what I initially tried to do here, but the problem is it fails
> for things like ToValue<std::vector<...>>() since there's no
> std::vector::Serialize(). I then tried some increasingly complicated template
> gymnastics and in the end got something that worked, but clang warned that it
> was *technically* against the spec which wasn't a good sign :)
> 
> I think the other alternative would be to have a virtual base class for all
user
> types so we can specialize ToValueImpl just for them, but I decided to go with
> this approach instead since most of the overhead evaporates at build time.
Makes sense.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
headless/lib/browser/type_conversions_h.template:62:
std::unique_ptr<base::Value> ToValueImpl(const {{namespace}}::{{type.id}}&
value, T*) {
On 2016/04/15 14:43:45, Sami wrote:
> On 2016/04/14 18:01:54, dgozman wrote:
> > I see two absolutely identical instances of this in generated file:
> > std::unique_ptr<base::Value> ToValueImpl(const dom::CopyToResult& value, T*)
> 
> Hmm, where? I can only find one.

My bad. Confused CopyToResult with CopyToParams.

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
File headless/lib/browser/types_h.template (right):

https://codereview.chromium.org/1805983002/diff/520001/headless/lib/browser/t...
headless/lib/browser/types_h.template:19: // ------------- Forward declarations
and typedefs.
On 2016/04/15 14:43:45, Sami wrote:
> On 2016/04/14 18:01:54, dgozman wrote:
> > In generated files I see a forward declaration for class CopyToResult, but
not
> > actual definition.
> 
> Do you mean here?
> 
> https://drive.google.com/corp/drive/u/1/folders/0ByyxMXB38gLDdmp4UGhzdThHQ1U
> 
> I just noticed that drive is a bit dumb: you have to scroll all the way to the
> bottom to make sure the whole file is loaded. CopyToResult only shows up after
> that :P

Wow. A serious usability decision here :-)

[Sami, 2016-04-18 09:45:57]

On 2016/04/15 20:51:13, dgozman wrote:
> Overall, this looks good. Sorry, didn't really look into every single line of
> templates and tests, but generated files are fine.
> 
> I guess, we will follow up with hidden/experimental story?

Thanks for looking. Yep, hidden/experimental will come next, along with events.

[altimin, 2016-04-20 11:04:29]

lgtm

[Sami, 2016-04-20 11:09:03]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2016-04-20 11:09:15]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1805983002/540001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1805983002/540001

[commit-bot: I haz the power, 2016-04-20 11:33:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-20 11:33:19]

Try jobs failed on following builders:
  linux_chromium_gn_chromeos_rel on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Sami, 2016-04-20 11:55:01]

The CQ bit was checked by skyostil@chromium.org

[Sami, 2016-04-20 11:55:02]

The patchset sent to the CQ was uploaded after l-g-t-m from altimin@chromium.org
Link to the patchset: https://codereview.chromium.org/1805983002/#ps560001
(title: "Make PendingMessage moveable")

[commit-bot: I haz the power, 2016-04-20 11:55:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1805983002/560001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1805983002/560001

[commit-bot: I haz the power, 2016-04-20 13:45:27]

Description was changed from

==========
headless: Implement client API generation

Implement a C++ client API which can be used to control and
inspect a tab in the headless browser. The API consists of
C++ bindings for the DevTools remote debugging protocol and
is automatically generated from the protocol definition.

Design doc:
https://docs.google.com/document/d/1rlqcp8nk-ZQvldNJWdbaMbwfDbJoOXvahPCDoPGOw...

BUG=595353
==========

to

==========
headless: Implement client API generation

Implement a C++ client API which can be used to control and
inspect a tab in the headless browser. The API consists of
C++ bindings for the DevTools remote debugging protocol and
is automatically generated from the protocol definition.

Design doc:
https://docs.google.com/document/d/1rlqcp8nk-ZQvldNJWdbaMbwfDbJoOXvahPCDoPGOw...

BUG=595353
==========

[commit-bot: I haz the power, 2016-04-20 13:45:28]

Committed patchset #29 (id:560001)

[commit-bot: I haz the power, 2016-04-22 19:23:10]

Description was changed from

==========
headless: Implement client API generation

Implement a C++ client API which can be used to control and
inspect a tab in the headless browser. The API consists of
C++ bindings for the DevTools remote debugging protocol and
is automatically generated from the protocol definition.

Design doc:
https://docs.google.com/document/d/1rlqcp8nk-ZQvldNJWdbaMbwfDbJoOXvahPCDoPGOw...

BUG=595353
==========

to

==========
headless: Implement client API generation

Implement a C++ client API which can be used to control and
inspect a tab in the headless browser. The API consists of
C++ bindings for the DevTools remote debugging protocol and
is automatically generated from the protocol definition.

Design doc:
https://docs.google.com/document/d/1rlqcp8nk-ZQvldNJWdbaMbwfDbJoOXvahPCDoPGOw...

BUG=595353

Committed: https://crrev.com/564a123cb9c2786db2b382a7f519cfbc65ae5e2f
Cr-Commit-Position: refs/heads/master@{#388488}
==========

[commit-bot: I haz the power, 2016-04-22 19:23:11]

Patchset 29 (id:??) landed as
https://crrev.com/564a123cb9c2786db2b382a7f519cfbc65ae5e2f
Cr-Commit-Position: refs/heads/master@{#388488}

[Nico, 2016-10-10 16:49:00]

thakis@chromium.org changed reviewers:
+ thakis@chromium.org

[Nico, 2016-10-10 16:49:02]

https://codereview.chromium.org/1805983002/diff/560001/headless/BUILD.gn
File headless/BUILD.gn (right):

https://codereview.chromium.org/1805983002/diff/560001/headless/BUILD.gn#newc...
headless/BUILD.gn:292: action("client_api_generator_tests") {
1) tests should run as part of running tests, not as part of the build
2) the build should be silent. this step prints a bunch of "running tests" lines

[Sami, 2016-10-11 00:14:03]

https://codereview.chromium.org/1805983002/diff/560001/headless/BUILD.gn
File headless/BUILD.gn (right):

https://codereview.chromium.org/1805983002/diff/560001/headless/BUILD.gn#newc...
headless/BUILD.gn:292: action("client_api_generator_tests") {
On 2016/10/10 16:49:02, Nico wrote:
> 1) tests should run as part of running tests, not as part of the build
> 2) the build should be silent. this step prints a bunch of "running tests"
lines

Sorry about that; Fix here: https://codereview.chromium.org/2411563002/

As far as I can tell GN doesn't seem to have built-in support for non-C++ tests
so I'll just make this a manual test for now and see about updating the bot to
run this explicitly.

[Lei Zhang, 2017-03-29 10:12:11]

thestig@chromium.org changed reviewers:
+ thestig@chromium.org

[Lei Zhang, 2017-03-29 10:12:13]

So I got roped into reviewing a headless/ CL and now I'm looking around and
there are things I don't understand. I haven't been able to find the answer, so
I figured I'd just ask on the relevant code reviews.

What is the usage policy for headless/public/internal? Is it actually public? If
not, why does it have to be in headless/public?

[Sami, 2017-03-29 10:19:33]

On 2017/03/29 10:12:13, Lei Zhang wrote:
> So I got roped into reviewing a headless/ CL and now I'm looking around and
> there are things I don't understand. I haven't been able to find the answer,
so
> I figured I'd just ask on the relevant code reviews.
> 
> What is the usage policy for headless/public/internal? Is it actually public?
If
> not, why does it have to be in headless/public?

Anything in the namespace headless::internal can be considered an implementation
detail. Think of it as base::internal. It's only under the public directory
because some of the public headers transitively depend on the internal bits --
users of headless should not directly depend on them.

[Lei Zhang, 2017-03-29 10:35:22]

On 2017/03/29 10:19:33, Sami wrote:
> On 2017/03/29 10:12:13, Lei Zhang wrote:
> > So I got roped into reviewing a headless/ CL and now I'm looking around and
> > there are things I don't understand. I haven't been able to find the answer,
> so
> > I figured I'd just ask on the relevant code reviews.
> > 
> > What is the usage policy for headless/public/internal? Is it actually
public?
> If
> > not, why does it have to be in headless/public?
> 
> Anything in the namespace headless::internal can be considered an
implementation
> detail. Think of it as base::internal. It's only under the public directory
> because some of the public headers transitively depend on the internal bits --
> users of headless should not directly depend on them.

Only the generated headers right? I didn't see any checked in files in present
day code search that uses headless/public/internal.

[Lei Zhang, 2017-03-29 10:36:30]

BTW, some comments that still apply to ToT and is generally useful.

https://codereview.chromium.org/1805983002/diff/560001/headless/public/domain...
File headless/public/domains/types_unittest.cc (right):

https://codereview.chromium.org/1805983002/diff/560001/headless/public/domain...
headless/public/domains/types_unittest.cc:14: EXPECT_TRUE(object);
Before accessing foo_ptr_like_obj, you need to ASSERT_TRUE(). Otherwise a NULL
deref crashes the entire test suite and all the subsequent tests in the suite
don't get a chance to run.

https://codereview.chromium.org/1805983002/diff/560001/headless/public/domain...
headless/public/domains/types_unittest.cc:23: const char* json = "{\"nodeId\":
\"foo\"}";
const char json[] = "foo";

Otherwise one can write: json = nullptr;

https://codereview.chromium.org/1805983002/diff/560001/headless/public/domain...
headless/public/domains/types_unittest.cc:131: EXPECT_EQ(3u,
object->GetNodeIds()->size());
ASSERT_EQ() before accessing elements - potential out of bounds.

[Sami, 2017-03-29 10:41:41]

On 2017/03/29 10:35:22, Lei Zhang wrote:
> Only the generated headers right? I didn't see any checked in files in present
> day code search that uses headless/public/internal.

That's right.