tree 6e3a00d09db394f0726e5cc32e68d517f250d19a
parent b352546be44551f5aabc428ac4d0cc161cd1b2ec
author David Benjamin <davidben@google.com> 1682104344 -0400
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1682521578 +0000

Don't copy all of bssl-sys into the CMake build directory

Instead, just have it look for the files it needs via a
BORINGSSL_BUILD_DIR environment variable. This avoids hardcoding
"../../build" anywhere that cannot be easily overriden by the user.

Although this puts logic in a build.rs file, which is problematic for
repositories with more coherent build stories like Android or Chromium,
those are already driving the bindgen and link process themselves,
without calling CMake. I.e. this file should already only be used for
standalone development and testing and not directly impact them. (Though
we'd like to keep it vaguely analogous to better predict without a
change will impact downstream folks.)

For now, I've kept bindgen generated from CMake, mostly in anticipation
of using the inline functions feature. Building the synthesized C file
from CMake seems less of a headache than Cargo. Additionally, calling
bindgen from the command-line is closer to how those consumers will do
it, so this forces us to stick to bindgen invocations that can be
expressed via command-line arguments. (E.g. the mess that is regexes and
escaping.)

As part of this, I've removed the messy "find the first matching wrapper
file" behavior in build.rs. Instead, it knows the expected TARGET and
just finds the file with matching name. This means we'll be stricter
about matching the two. (Otherwise there's no point in naming it by
target name anyway.)

Fixed: 598
Change-Id: I07fa74f7e5f5f008d6f0ceec648a2378df7d317a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59105
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Nabil Wadih <nwadih@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>