Inspecting/reusing `sources` or `public_deps` of another target

[Łukasz Anforowicz]

Hello gn-...@chormium.org,

I wonder if you could please help me with some GN questions (at the end of this email / after a long introduction :-).

As part of Chromium Rust Experiment project, I am trying to integrate Crubit support into Chromium's build system.  So far, something like that works (on my machine :-P):

rust_executable("my_target") {
  crate_root = "main.rs"
  sources = [ "main.rs" ]
  deps = [ ":teleport_rs_api" ]
]

# This will generate "teleport_rs_api" target that provides Rust
# bindings for the "teleport.h" header from the ":teleport" source
# set.
rs_bindings_from_cc("teleport_rs_api") {
  bindings_target = ":teleport"
  public_headers = ["teleport.h"]
  deps = [ ":goat_rs_api" ]  # Parallel's `public_deps` of ":teleport"
}

source_set("teleport") {
  sources = [ "teleport.h", ... ]
  public_deps = [ ":goat" ]
}

rs_bindings_from_cc("goat") {
  public_headers = ["goat.h"]
}
source_set("goat") {
  sources = [ "goat.h", ... ]
}

It would be nice if users of the `rs_bindings_from_cc` gni template didn't have to specify `public_headers` and/or `deps` manually:

• `deps` should in most cases just default to `public_deps` of the `bindings_target`, but with `_rs_api` suffixes.
• `public_headers` can oftentimes just list all the C++ headers from `sources` of the `bindings_target`.  If some headers are non-public, then they still need to be discovered and included in the GN `metadata` exposed by the expansion of the `rs_bindings_from_cc` template (so that Crubit can figure out which target defines a given struct by mapping #include paths via Crubit's `--targets_and_headers` cmdline argument).

QUESTIONS:

• Is there a way to read `public_deps` or `sources` of another target?  `get_label_info` doesn't seem to cover that.
• Do you have any feedback on the overall design outlined above?
• Maybe forcing explicit / separate / manual entries is desirable after all?  Maybe too much magic (adding _rs_api suffixes to target names, defaulting to treating all headers as public) can result in a confusing experience.
• FWIW, Crubit's Bazel support doesn't require an explicit / separate / manual target - if using Crubit, then `rust_library` can just depend on `cc_library` (without going through an intermediate `rs_api` target as in the design I sketched out above).  But then, Crubit can ask Bazel to get public headers via `hdrs`, private headers via `srcs` and `textual_hdrs` (and dependencies are tightly managed - it is impossible to include a header unless it has been declared as a dependency).

Thanks,

Lukasz

[Łukasz Anforowicz]

/CC @Marcel Hlopko and @Rosica Dejanovska from the Crubit project - mostly just as an FYI

[Brett Wilson]

In your specific case, you can have a

  foo_sources = [ ... ]

at the top of the file and then reference this below

  sources = foo_sources + [ "bar.cc" ]

in the various places so you don't need to respecify the headers. I don't know how well this will scale to an entire project or how much this will need to be duplicated.

You can encapsulate much of this behavior in a template. Fuchsia does some of this kind of thing in templates (adding suffixes to deps labels), but IMO it does too much in some cases and the discoverability isn't great and the failure cases are unpleasant. I believe Fuchsia will do things like have "some_special_deps" variable that is processed by appending suffixes, and then another template deps variable that has the normal behavior.

Your examples said "in most cases" and "oftentimes" and that means that if you made a way to do this you have to have a way to override the default behavior. And the default behavior and the override syntax need to be discoverable by somebody who doesn't know what they're doing.

My feeling on the build is that almost nobody that's changing the files knows how it really works, so it's better to be verbose in a straightforward way that can be copy/pasted and changed in an obvious way than have magic that won't be discoverable by such users.

Brett