[WIP] Define per-cluster server and client targets in GN #36917
Conversation
Have chip_data_model targets depend on these, instead of making up a source set on the fly.
|
PR #36917: Size comparison from c1afc02 to 5728f01 Full report (3 builds for cc32xx, stm32)
|
| ":time-sync-data-provider-test-srcs", | ||
| "${chip_root}/src/app", | ||
| "${chip_root}/src/app:attribute-persistence", | ||
| "${chip_root}/src/app/clusters/thread-network-directory:server", |
There was a problem hiding this comment.
we should name the targets for cluster foo as foo so that the server suffix is not necessary (i.e. typical/default should have the same name as the directory, extra bits should be differently named if necessary)
There was a problem hiding this comment.
I was thinking we could have client and server in the same directory, for those where client code exists?
| @@ -75,3 +75,11 @@ source_set("callbacks") { | |||
| "${chip_root}/src/app:paths", | |||
| ] | |||
| } | |||
|
|
|||
| source_set("binding-table-headers") { | |||
| sources = [ "binding-table.h" ] | |||
There was a problem hiding this comment.
we should not split cpp from header. Even this is what happens in practice, this allows for circular/odd dependencies. We should add source sets only when we are able to fix things.
There was a problem hiding this comment.
I agree in general, but I think this is a somewhat special case where we have an API that consists of some global functions that these cluster implementations can compile against, but the implementation of those functions relies on the application-level zap codegen. Without separating this we can't model this kind of link-time dependency (rather than a standard compile-time dependency).
I think being able to compile cluster implementations along with the core, and only requiring the generated code to be present at link time is a step forward from having to compile everything as part of the application's data model source set. Or is your new data model API work at a point where we can remove the dependency on zap-generated code entirely?
(Same story with the ember-api.h you've commented on below really. I would probably actually prefer to have a single header bundling all of these link-time dependencies on zap-generated code (for as long as we have to have them), and just treat that as a documented special case; as you say it's not a good pattern in general.)
| * This function returns true if | ||
| * the endpoint contains client of a given cluster. | ||
| */ | ||
| bool emberAfContainsClient(chip::EndpointId endpoint, chip::ClusterId clusterId); |
There was a problem hiding this comment.
this splits the logic of "if xyz is defined in foo.h, it is implemented in foo.cpp". As a result then we have a "ember-api.h" that is available standalone even though the functions that it defines are not linked in and this breaks dependencies.
|
|
||
| import("//build_overrides/chip.gni") | ||
|
|
||
| source_set("server") { |
There was a problem hiding this comment.
| source_set("server") { | |
| source_set("thread-network-directory") { |
|
|
||
| import("//build_overrides/chip.gni") | ||
|
|
||
| source_set("server") { |
There was a problem hiding this comment.
| source_set("server") { | |
| source_set("wifi-network-management") { |
| } | ||
|
|
||
| source_set("ember-api-headers") { | ||
| sources = [ "ember-api.h" ] |
There was a problem hiding this comment.
we should not have a header without the implementation cpp unless that header defines constants only. I.e. if I depend on foo I should be able to link. This breaks that.
Have chip_data_model targets depend on these, instead of making up a source set on the fly.
Early preview of this idea.