Build macros in earlier versions of Bazel (pre-1.0) needed to specify
targets in a different format, depending from where they were
included/expanded at build time.
For example, a `sapi_library()` macro invocation in one of the directories
under `examples`, always needed to depend on the SAPI main library as
`//sandboxed_api:sapi`. When using SAPI from another Bazel project, the
same macro would have needed to depend on
`@com_google_sandboxed_api//sandboxed_api:sapi`. The `sapi_library()`
macro was thus checking the repository name and conditionally changed
the dependencies. This approach is brittle and as of Bazel 3.1.0 no
longer works.
This CL simple removes the conditional prefix and unconditionally uses
`@com_google_sandboxed_api`.
Tested on Bazel 1.2.1, 2.2.0 and 3.1.0
Drive-by:
- Make Bazel config action more robust
- Disable dependency tracking in libunwind configure
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
- Same upstream dependency versions for CMake and Bazel
- Use maybe() from build_defs to conditionally define Bazel repositories
PiperOrigin-RevId: 282331418
Change-Id: I8a7db84a1d3115f3c1f31cc1dfcc8c29fe391a62
These where inadvertently introduced in an internal cleanup change.
This change also removes a C++17-ism in var_proto.h. To make things easier for
downstream projects, we should stick to C++11 for the time being.
PiperOrigin-RevId: 271117700
Change-Id: I4eaacec88be16e1a561d3f77a61acce0a1af0b9d
The temporary solution for binaries/tests that fully statically linked is to
link against `gflags` using `-Wl,--whole-archive`. This will no longer be
necessary, once Abseil ships with logging. Then we can (finally) use Abseil
flags and use a logging library that does not depend on a different flags
library.
PiperOrigin-RevId: 260705702
Change-Id: I8562faaff59f9c3e0e1d331186d2806d387438fb
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
Starting with Bazel 0.27.0 --incompatible_depset_is_not_iterable became the
default.
Fixes#27
PiperOrigin-RevId: 254703981
Change-Id: I727e4b1c6a907c8794a00f61646c13ad8d4437b7
This test runs, but fails due to a different problem:
StackTraceTest.ForkEnterNsLibunwindDoesNotLeakFDs
PiperOrigin-RevId: 251218516
Change-Id: If06cdbcb71fad84ebd9d934ff173d7ef1a1eebc0
- Add a superbuild in cmake/SuperBuild.cmake that downloads and builds
dependencies
- Builds for sandbox2/ and a its tests
- Helper CMake function to strip proto paths
- Module to find libcap
- Custom build for libunwind that wraps its symbols
- Fix environment so that CTest executes tests similar to Bazel
- Filewrapper functionality, like Bazel's cc_embed_data()
- Build forkserver with embedded binary
- Enable ASM language so that libunwind builds correctly
- Allow glog target to propagate transitively (to propagate its include dirs)
Signed-off-by: Christian Blichmann <cblichmann@google.com>
