services/viz/public/interfaces has dependency on both cc and components/viz/common. This is causing problems on adding things to components/viz/common that need to depend on services/viz/public/interfaces.

Why does it depend on cc? I think it shouldn't?

typemaps in services/viz/public/cpp have dependency on cc and components/viz/common. I tried simply commenting out cc dependency in typemaps and the dependency on cc was gone. But even then it deps on components/viz/common so still a circle dependency

>  This is causing problems on adding things to components/viz/common that need to depend on services/viz/public/interfaces.

I don't think the common code should be depending on the interface code, it should go the other way. What are you trying to do?

I'm trying to add a hit-test data builder class that both DirectlyLayerTreeFrameSink and ClientLayerTreeFrameSink can use, but it needs to include hit_test_region_list.mojom [1] for hit-test data structs.

[1] https://cs.chromium.org/chromium/src/services/viz/public/interfaces/hit_test/hit_test_region_list.mojom

> it needs to include hit_test_region_list.mojom [1] for hit-test data structs.

It sounds like those structs should be under components/viz/common/. The common dir there is for things used on both service and client - primarily for things passed over IPC.

Ohh are you suggesting that we have both mojom and c++ structs for hit-test data and have struct_traits to serialize/deserialize between them?

Those are mojom types. We do not have corresponding native/c++ types ... yet. I think having to introduce native-types just to work around this would be unfortunate.

It seems that we're writing c++ code that wants to use these structs, so c++ types seems okay?

> Ohh are you suggesting that we have both mojom and c++ structs for hit-test data and have struct_traits to serialize/deserialize between them?

I think so, and a struct traits to map between them, as we do for all other structs that we pass over IPC and make use of in the c++ code afaik.

The difference with other native types is that hit-test data is almost always generated on-demand, instead of persistently maintained in the code. So when we generate the data, we directly generate the mojom types. If we introduce new c++ types, then we would generate the c++ types, go through the struct-traits to generate the mojom types, and send over IPC (and the same conversion dance on the receiving end). This extra conversion would be unfortunate (and should be unnecessary).

I see. Well our our components/viz/ stuff has been built so that you can use it without knowing mojo interfaces, you can make direct pointers to things in the browser process or webview or whatever.

So where should we put code that is dependent on the services/ code and is part of the service?

I also think adding C++ classes for HitTestRegion[List] is the easiest way forward. It's a small upfront cost to write but allows us to design a better API for building and using the HitTestRegion data in the future.

Just a note, there is no extra conversion step for using our own C++ type. A StructTrait is auto-generated for mojom::HitTestRegionPtr mojom::HitTestRegionListPtr today and that conversion step still happens.

I've made services dep only on viz now in https://chromium-review.googlesource.com/c/chromium/src/+/1072314, as all the types it uses have been moved to viz, and I added a C++ class for HitTestRegion[List] in https://chromium-review.googlesource.com/c/chromium/src/+/1072128