This partially reverts the zlib change in 41e0ca0. Turns out the
`CMakeLists.txt` that ships with zlib leaves much to be desired.
PiperOrigin-RevId: 424800727
Change-Id: I356e3bb8d18461a52f845baa4913adff6549ef00
Now unwinding will properly handle binaries inside bind-mounted directories.
Drive-by:
- Get rid of n^2 path handling
- Get rid of namespace alias
PiperOrigin-RevId: 358353666
Change-Id: Ieec7690ec6a1ae6d358de375220566b69e8cb094
This removes our own fork of `absl::StatusOr<>`. Sandboxed API still includes
a custom matcher for Googletest, as that is not open source yet. For
compatibility, the `statusor.h` header is still retained and now aliases
`sapi::StatusOr<>` to `absl::StatusOr<>`.
PiperOrigin-RevId: 329916309
Change-Id: I0544b73a9e312dce499bc4128c28457e04ab9929
- Same upstream dependency versions for CMake and Bazel
- Use maybe() from build_defs to conditionally define Bazel repositories
PiperOrigin-RevId: 282331418
Change-Id: I8a7db84a1d3115f3c1f31cc1dfcc8c29fe391a62
Since the interface generator is invoked via a Bazel macro, it will be
expanded in the embedding context of the project using SAPI, so package access
needs to go through the full workspace root @com_google_sandboxed_api.
This change also modifies the CMakeLists.txt accordingly, as the "external"
subdirectory is no longer needed/wanted.
PiperOrigin-RevId: 255918784
Change-Id: I052c687509f65fef7f011a9d1a074a171595330f
If using Sandboxed API from an external Bazel WORKSPACE, dependencies can be
imported by declaring the repository and calling `sapi_deps()`:
```python
git_repository(
name = "com_google_sandboxed_api",
commit = "master",
remote = "https://github.com/google/sandboxed-api.git",
)
load(
"@com_google_sandboxed_api//sandboxed_api/bazel:sapi_deps.bzl",
"sapi_deps",
)
sapi_deps()
```
PiperOrigin-RevId: 255373664
Change-Id: I4c41ffc75e1ca95eb126702cb2d5cedb255191d5
