Bazel 3.x now requires specifying `commit`, `tag` or `branch` in its
`git_repository` rule.
PiperOrigin-RevId: 320572176
Change-Id: I81048d997f595202f4dfbd3c1e9c8321240a28a3
Otherwise ExecuteProcess is implicitly `[[noreturn]]` and this
might cause policy violations in `__asan_handle_no_return`
for ASAN builds.
PiperOrigin-RevId: 319203128
Change-Id: I5c8ba71ce88261f803aa3f16730eccea0d803dd1
--
fd2e99fa87c34f2fb1a20052c030ad7a4139b4e1 by Christian Blichmann <mail@blichmann.eu>:
Support LLVM >= 7.0.1 in Clang based header generator
This change glosses over small API changes introduced since LLVM/Clang
7.0.1, which ships with Debian Stable "Buster". Ubuntu 18.04 LTS "Bionic"
also shipped this (and subsequently updated to version 9).
Hence, compiling the generator should now work on all reasonable Debian
based distributions.
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/sandboxed-api/pull/44 from cblichmann:20200609-llvm-version-compat fd2e99fa87c34f2fb1a20052c030ad7a4139b4e1
PiperOrigin-RevId: 315637014
Change-Id: I6585041d8bebade15e44c057b1a69287bbc0e733
The "hello_sapi" example lives in a different WORKSPACE as it is intended to
show how to embed SAPI in your own projects. However, this is not compatible
with simply running `bazel build //sandboxed_api/...` after checkout.
This change simply replace `copts = ["-I."]` with `includes = ["."]`, so that
generated headers can be found reliably, regardless of how the example is
compiled.
PiperOrigin-RevId: 313782756
Change-Id: Iac26e828146b01545c81d9500f5f68fa0f2d4ddf
- Extract dependent types directly from the Clang AST and re-serialize
back into compilable code
- Collect types and emit diagnostics
- Format generated code
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
This change contains a "hello world"-style example library to be
sandboxed. It consists of a stand-alone CMake and Bazel project that
uses Sandboxed API as its dependency.
To use Sandboxed API in an external project, it should be enough to
copy the files in the `sandboxed_api/examples/hello_sapi` directory
as a starting point.
When using SAPI from an external project via CMake, the small zlib patch
cannot be found during the config phase.
This change also fixes an oversight in that the tests depend on some of
the example code.
Regardless embedding code should set `SAPI_ENABLE_EXAMPLES` to `OFF`.
Disabling tests by setting `SAPI_ENABLE_TESTS` to `OFF` stays optional.
PiperOrigin-RevId: 311290454
Change-Id: Ibe105895859b793b20f47c89b1a9e11cbfef2e2f
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
Similar to what the Bazel build does, this change adds zlib as an additional
dependency when `SAPI_ENABLE_EXAMPLES` is set to `ON`.
PiperOrigin-RevId: 309203959
Change-Id: I201a9e6415789afb1e058bc48cebbc0fc0004fe9
BoringSSL (which is the crypto library used by most Google products) is starting to use madvise(_, _, MADV_WIPEONFORK) to protect random-number state from being duplicated by fork(). This causes extra madvise calls that sandboxes need to permit in order to continue functioning.
PiperOrigin-RevId: 309173849
Change-Id: I007dacc1ff1fd0ccc138caaa08735cfe5bc78234
Fixes some template issues that could lead to code not compiling when it
otherwise should.
PiperOrigin-RevId: 308809964
Change-Id: I9f2f9d4aff5f1a9cb967fb705a86fd7f49114f7a
The underlying issue is with a Copybara transform and the internal Blaze BUILD file.
PiperOrigin-RevId: 308787839
Change-Id: I32af664b3eac4c925d39f50b967756198eff23f3
Note: This intentionally omits perfect-forwarding value assignments. This
avoids overly complex template expressions. The regular assignments are still
efficient.
PiperOrigin-RevId: 304159053
Change-Id: I3460f46ca5779a0619cf90ae22625de8fad7669c
Drive-by:
- Make Bazel config action more robust
- Disable dependency tracking in libunwind configure
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
When embedding SAPI in an external CMake project, the version of
`protobuf_generate_cpp` that we lifted from upstream protobuf produces
the wrong generated file paths.
For example, given this project structure:
```
/parent/
+-- myproject/
+-- myproject_build/ <- CMake build directory
+-- sandboxed-api/ <- Checkout from GitHub
```
And a CMake file in `myproject/CMakeLists.txt` that embeds SAPI like
this:
```
cmake_minimum_required(VERSION 3.12)
project(SandboxedTest LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_subdirectory(
${PROJECT_SOURCE_DIR}/../sandboxed-api
${PROJECT_BINARY_DIR}/sandboxed-api
)
```
Then `protobuf_generate_cpp` correctly invokes the protoc compiler to
generate
`/parent/myproject_build/sandboxed-api/sandboxed_api/proto_arg.proto.pb.cc'.
However, the path of the generated source file that is passed to the C++
compiler will be
`/parent/myproject_build/sandboxed-api/sandboxed_api/../../myproject_build/sandboxed-api/sandboxed_api/proto_arg.pb.cc`.
Note the duplicated project build directory component in the
canonicalized version:
`/parent/myproject_build/myproject_build/sandboxed-api/sandboxed_api/proto_arg.pb.cc`.
This change simple omits the computation of any relative file paths and
simply uses `_pb_PROTOC_OUT_DIR` which defauls to
`CMAKE_CURRENT_BINARY_DIR`, which should always contain the correct
path.
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
Created documentation for network proxy. fixed 2 things in documentation (namespaces are enabled by default for a while).
PiperOrigin-RevId: 300321016
Change-Id: Id9c54b29551e8d3b70e814e2fdbfee594126aa90
Currently we extract all functions from the compilation unit - it doesn't really make sense as it will try to process functions in included files too.
As we require sapi_in flag, we have information which files are of interest.
This change stores the top path in _TranslationUnit and uses it when looking for function definitions to filter only functions from the path we provided.
PiperOrigin-RevId: 297342507
Change-Id: Ie411321d375168f413f9f153a606c1113f55e79a
The next release contains one major change: for function parameter annotations,
pytype will no longer treat (x: X = None) as equivalent to
(x: Optional[X] = None). This pytype behavior was based on an outdated version
of the type-checking spec. Annotations that were relying on the behavior now
need to explicitly declare themselves as Optional.
PiperOrigin-RevId: 297065077
Change-Id: Iade679e5928bb3839485e8b8571945456ba6e982
