tree 19adbd8aff9be47f54692dcdfde9ce21ca76fc25
parent 3cdf64a82fa4e239a3fdd419571749c814232c1f
author Marcel Hlopko <hlopko@google.com> 1636125680 +0000
committer Marcel Hlopko <hlopko@google.com> 1648245666 +0000

Pass target and header information to the rs_bindings_from_cc tool during the build

In this CL we add --targets_and_headers flag, currently noop, that contains
following data in JSON format:

[
  {"t": "//foo/bar:baz", "h": ["foo/bar/baz/header1.h", "foo/bar/baz/header2.h"]},
  {"t": "//base:base", "h": ["base/header1.h", "base/header2.h"]},
  ...
]

JSON was chosen for following reasons:

* absl flags don't natively support repeated flags that accumulate result (in
  other words, if one flag is present multiple times on the command line, the
  last one wins unconditionally).
* if we want to emulate repeated flags, we have to encode the format, or
  separators, somehow.[]
  allowed as target name, so we have 2 options:
  1) we either escape special characters, and if we have to go that way, let's
     just admit defeat and use JSON. This is what we do here.
  2) we use uncommon combinations (for example tripple semicolon as line
     separator, and tripple comma as a column separator. We detect these patterns
     and we fail the build on a conflict.
* not currently the case, but there is a potential for performance optimization
  in blaze - we have to generate JSON from a depset, and Blaze could cache
  generated JSON snippets from transitive depsets.

I'm happy to choose 2) (because it only occured to me while writing the CL
description, and the 1) was already implemented :)

This design can also be revisited once/if we move from cc_binary to rust_binary, and using a different flags library than absl.

Actual logic that uses the flag in the tool will come as a followup.

PiperOrigin-RevId: 407826722